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为 什么 要 写 这 本 书 


作为 置 喘 于 I 技术 领域 多 年 的 实践 者 和 教育 者 ， 我 们 一 直 盼 望 着 行 
业 迎 来 这 样 一 个 时 刻 : 异 构 的 开 基 础 设施 环境 所 造成 的 开发 和 部 署 系统 
应 用 纷 索 复 杂 的 局 面 终于 迎 来 了 终结 者 ， 开 发 人 员 无 须 再 考虑 复杂 多 样 
的 运行 环境 下 软件 程序 的 移植 问题 ， 运 维和 人 员 不 用 再 手动 解决 运行 环境 
中 组 件 间 的 依赖 关系 等 ， 从 而 让 各 目的 核心 职 贡 都 回归 到 开发 和 保证 系 
统 稳定 运行 本 身 。 终 于 ， 以 Docker 为 首 的 容器 技术 为 此 带 来 了 基础 保 
隐 ， 并 在 容器 编排 技术 的 文 撑 下 尘埃 落 定 ， 其 至 连 IT 管理 者 心心 念 念 
年 的 DevOps 文 化 运动 也 借 此 找到 了 易于 落地 的 实现 方案 。 于 是 ， 系 统 
运行 割据 多 年 的 局 面 终 于 将 走 同 天 下 一 统 。 


尽管 距 Kubernetes 1.0 的 发 布 不 过 三 四 年 的 光景 ， 但 其 如 今 的 影响 力 
在 IT 技术 领域 完全 算得 上 空前 绝 后 ， 目 前 ， 一 众 大 小 公司 都 在 使 用 或 正 
筹划 使 用 这 一 IT 技术 发 展 史 上 可 能 最 为 成 功 的 开源 项 目 。Linux 软 件 基 
金 会 的 常务 董事 Jim Zemlin 在 Google Cloud Next 17 大 会 上 曾 表 示 ， 
Kubernetes 是 “ 云 时 代 的 Linux”。 的 确 ，Kubernetes 应 该 是 开源 世界 有 史 
以 来 欠 代 最 快 的 项 目 ， 而 且 在 几乎 所 有 需要 采用 容器 技术 的 场景 里 成 为 
占 统治 地 位 的 解决 方案 ， 其 友 展 速度 恕 怕 也 仅 有 Linux 内 核 项 目 可 堪 匹 
收 。2018 年 3 月 ，Kubernetes 成 为 CNCE 旗 下 “毕业 ”的 第 一 个 项 目 ， 并 荣 
获 2018 年 OSCON 最 具 影 响 力 奖 项 。 


目前 ，Kubermnetes 保 持 着 每 年 发 布 四 个 重要 版 本 的 节奏 ,版 本 的 每 
次 更 新 都 会 引入 数 个 新 特性 。 这 种 快速 迭代 的 机 制 在 为 用 户 不 断 融 来 惊 
喜 的 同时 ， 也 给 他 们 在 学 习 和 使 用 上 造成 了 一 些 困 扰 : 相关 领域 的 可 参 
考 书籍 仍 不 丰 寅 ， 互 联网 上 可 以 得 到 的 众多 文档 并 非 源 于 同一 个 版 本 ， 
以 及 厘清 脉络 拼 读 成 完整 的 知识 框架 所 需 的 时 间 成 本 较 大 。 因 此 ， 我 在 
课程 以 及 直接 或 间接 参与 生产 或 测试 环境 的 交付 之 余 便 萌 生 了 撰写 一 本 
Kubernetes 入 门 、 进 阶 与 实战 的 书籍 的 想法 ， 将 目 己 学 习 和 使 用 的 经 验 
总 结 、 沉 深 并 分 享 给 更 多 有 此 需求 的 技术 同行 ， 帮 助 大 家 快速 找到 入 门 
路 径 ， 降 低 时 间 成 本 ， 并 迅速 投入 测试 和 生产 之 用 。 


的 确 ， 在 写作 过 程 中 ，Kubernetes 这 种 快速 迭代 的 机 制 ， 以 及 每 每 


























引入 的 新 特性 ， 在 小 惊喜 之 余 带 给 笔者 更 多 的 却 是 真 真切 切 的 梦 厦 般 的 
了 芍 惧 感 : 在 一 年 多 的 写作 时 间 里 ， 许 多 章节 几 易 其 稿 ， 却 也 依然 无 法 确 
保 能 够 涵盖 即将 成 为 核心 功能 的 特性 ， 于 是 诅 丧 感 儿 度 如 影 随 形 ， 直 到 
自我 安奈 着 “基础 的 核心 特性 基本 不 会 友 生 大 的 变动 ， 只 要 能 帮助 读者 
弄 清楚 Kubernetes 系 统 的 基础 架构 及 核心 工作 逻辑 就 算 工 夫 没 有 白费 ”之 
后 方才 释然 。 于 是 便 有 了 这 本 力图 尽量 多 地 包罗 Kubernetes 系 统 目 前 主 
流 特性 及 实践 路 径 的 入 门 和 进 阶 之 书 、 工 具 之 书 。 


本 书 特色 


本 书 致力 于 帮助 容器 编排 拉 术 的 初级 和 中 级 用 户 循 序 渐进 地 理解 与 
使 用 Kubernetes 系 统 ， 因 此 本 书 的 编写 充分 考虑 到 初学 者 进入 新 知识 领 
域 时 的 甘 然 ， 采 用 由 浅 入 深 、 提 纲 者 领 、 再 由 点 到 面 的 方式 讲解 每 一 个 
知识 细节 。 对 于 每 个 知识 点 ， 不 仅 介 绍 了 其 概念 和 用 法 ， 还 分 析 了 为 什 
么 要 有 这 个 概念 ， 实 现 的 方式 是 什么 ， 背 后 的 逻辑 为 何 ， 等 等 ， 使 读者 
不 仅 能 知 其 然 ， 还 能 知 其 所 以 然 。 


本 书 不 仅 要 带领 读者 入 门 ， 更 是 一 本 可 以 随时 动手 加 以 验证 的 实践 
手册 ， 而 且 对 于 部 分 重要 的 内 容 还 会 专门 一 步 步 地 给 出 具体 的 实 操 案 
例 ， 帮 助 读者 在 实践 中 升华 对 概念 的 理解 。 本 书 几乎 涵盖 了 应 用 
Kubernetes 系 统 的 所 有 主流 知识 点 ， 它 其 至 可 以 作为 计划 考取 CKA 认 证 
的 读者 的 配套 参考 图 书 。 























读者 对 象 
` 云 计算 工程 师 
` 运 维 工 程 师 
系统 开发 工程 师 
-程序 架构 师 
-计划 考取 CKA 认 证 的 人 员 
其 他 对 容器 编排 感 兴 趣 的 人 员 





如 何 阅 读本 书 

阅读 使 用 本 书 之 前 ， 读 者 需要 具备 Docker 容 器 技术 的 基础 使 用 能 
力 。 本 书 逻 辑 上 共 分 为 五 大 部 分 ，15 章 。 

第 一 部 分 〈 第 1 一 2 章 ) ， 介 绍 Kubernetes 系 统 的 基础 概念 及 其 基本 

第 1 章 介绍 容器 编排 系统 出 现 的 背景 ， 以 及 Kubernetes 系 统 的 功 
能 、 特 性 、 核 心 概念 、 系 统 组 件 及 应 用 模型 。 


第 2 章 讲解 Kubernetes 的 核心 对 象 ， 以 及 直接 使 用 命令 管理 资源 对 
象 的 快速 入 门 技巧 。 


第 二 部 分 〈 第 3 一 6 章 ) ， 介 绍 核心 资源 类 型 及 其 应 用 。 


命令 对 比 说 明 两 种 操作 方式 的 不 同 之 处 。 
第 4 章 介绍 Pod 资 源 的 常用 配置 、 生 命 周期 、 存 储 状态 和 就 绪 状 态 
检测 ， 以 及 计算 资源 的 需求 及 限制 等 。 


第 5 章 介绍 Pod 控 制 器 资源 类 型 ， 重 点 讲解 了 控制 无 状态 应 用 的 
ReplicaSet、Deployment、DaemonSet 控 制 器 ， 并 介绍 了 Job 和 CronJob 控 
制 器 O 


第 6 章 介绍 Service 和 Ingress 资 源 类 型 ， 涵 盖 Service 类 型 、 功 用 及 其 
实现 ， 以 及 Imgress 控 制 器 、Ingress 资 源 的 种 类 及 其 实现 ， 并 通过 案例 详 
细 说 明了 Ingress 资 源 的 具体 使 用 方式 。 

第 三 部 分 〈 第 7 一 9 章 ) ， 介 绍 存储 卷 及 StatefulSet 控 制 器 。 


第 7 章 主要 介绍 存储 卷 类 型 及 常见 存储 卷 的 使 用 方式 、PV 和 PVC 出 
现 的 原因 及 应 用 ， 以 及 存储 类 资源 的 应 用 和 存储 郑 的 动态 供给 。 


第 8 章 介绍 使 用 一 等 资源 类 型 ConfigMap 和 Secret 为 容器 应 用 提供 配 
置 及 敏感 信息 的 方式 。 








第 9 章 主要 介绍 有 状态 应 用 的 Pod 控 制 器 资源 StatefulSet， 包 括 基础 
应 用 、 动 态 扩 缩 容 及 更 新 机 制 等 。 


第 四 部 分 〈 第 10 一 11 章 ) ， 介 绍 安全 相关 的 话题 ， 主 要 涉及 认证 、 
授权 、 准 入 控制 、 网 络 模 型 与 网 络 策略 。 


第 10 章 重点 讲解 认证 方式 、Service Account 和 TLS 认 证 、 授 权 插 件 
类 型 及 RBAC， 并 于 章节 的 最 后 介绍 LimitRanger、ResourceQuota 和 
PodSecurityPolicy 三 种 类 型 的 准 入 控制 器 及 相关 的 资源 类 型 。 


第 11 章 主要 介绍 网 络 插件 基础 及 flannel 的 三 种 后 端 实 现 与 应 用 、 借 
助 Canal 插 件 实现 网 络 策 略 的 方式 ， 以 及 Calico 网 络 插件 的 基础 使 用 。 


第 五 部 分 〈 第 12 一 15 章 ) ， 介 绍 Kubernetes 系 统 的 高 级 话题 。 


第 12 章 介绍 Pod 资 源 的 调度 条 略 及 高 级 调度 方式 的 应 用 ， 包 括 操 
杀 和 、Pod 资 源 杀 和 以 及 基于 污点 和 容忍 度 的 调度 。 


第 13 章 介绍 系统 资源 的 扩展 方式 ， 包括 目 定义 资源 类 型 、 目 定义 
资源 对 象 、 目 定义 API 及 控制 器 、Master 节 点 的 高 可 用 、 基 于 Kubernetes 
的 PaaS 系 统 等 话题 。 


第 14 章 介绍 资源 指标 、 自 定义 指标 、 监 控 系 统 及 HPA 控 制 器 的 应 
用 。 


第 15 章 介绍 简化 应 用 管理 的 工具 Helm， 并 基于 Helm 介 绍 如 何 为 
Kubernetes 系 统 提供 统一 的 日 志 收 集 与 管理 工具 栈 EFK。 


有 一 定 Kubernetes 使 用 经 验 的 读者 可 以 挑选 感 兴趣 的 章节 阅读 。 而 
对 于 初学 者 ， 建 议 从 基础 部 分 逐 章 阅读 ， 但 构建 在 Kubernetes 系 统 之 上 
的 应 用 多 数 都 要 求 读 者 能 熟练 使 用 相关 领域 的 知识 和 技能 ， 如 果 对 某 些 
内 容 的 理解 比较 困难 ， 那 么 可 能 是 由 于 相关 知识 欠缺 ， 建 议 读 者 通过 其 
他 资料 补充 学 习 相关 知识 后 再 阅读 本 书 。 编 撰 本 书 的 主要 意图 是 为 初学 
者 提供 一 个 循序 渐进 的 实 操 手 册 ， 不 过 ， 任 何 读者 也 都 可 以 将 它 作为 一 
本 案头 的 工具 书 随时 进行 查阅 。 




















排版 约定 


本 书 中 所 有 的 命令 都 附带 了 或 长 格式 或 短 格式 的 命令 提示 符 ， 以 便 
读者 区 分 文中 正 第 使 用 的 “#* 和 “$”， 命 令 提 示 格 式 为 “~]#" 或 “~]$”， 较 
ee 了 史 为 续 行 符 ， 且 命令 及 其 输出 使 用 了 有 别 于 正文 的 字 


更 多 内 容 和 附带 代码 


本 书 相 关 的 配置 清单 等 都 放置 于 https://github.com/ikubernetes/ 的 相 
关 仓 库 中 ， 在 实践 中 需要 时 可 直接 克隆 至 本 地 实验 环境 中 使 用 。 


勘误 和 文 持 


尽管 进行 授课 及 技术 写作 已 十 数 年 ， 但 动笔 闭 书 沿 必 首次， 考虑 到 
排版 印刷 后 的 表述 无 可 更 改 ， 整 个 写作 过 程 战 战 殉 奖 、 如 履 薄 六 。 进 行 
每 一 个 关键 话题 的 表述 之 前 都 查阅 了 大 量 资 料 ， 并 且 反 复 其 酌 ， 既 期 望 
能 够 将 知识 点 清晰 、 准 确 地 加 以 描述 ， 也 试图 避免 因 上 自己 的 理解 偏差 而 
误导 读者 。 尽 管 如 此 ， 由 于 笔者 水 平 有 限 ， 加 之 编写 时 间 人 仓促 ， 书 中 难 
免 存 在 不 妥 之 处 ， 恳 请 读者 批评 指正 。 如 果 读 者 有 更 多 的 宝贵 意见 ， 请 
通过 邮箱 mage@magedu.com 联系 我 ， 期 竺 能够 得 到 你 们 的 真挚 反馈 ， 
在 技术 之 路 上 互 勉 共 进 。 另 外 ， 本 书 的 勤 误 将 会 发 布 在 笔者 的 博客 
Chttp:/www.ilinux.io ) 或 本 书 专用 的 GitHub 主 页 
《https://github.com/ikubernetes ) 上， 欢迎 读者 朋友 们 关注 并 留言 讨 
论 ， 

















参考 资料 





对 于 具有 不 同 知识 基础 和 结构 的 读者 来 说 ， 仅 赁 一 本 书 的 内 容 根本 
不 足以 获取 所 需 的 全 部 信息 ， 大 家 还 可 以 通过 以 下 信息 获取 关于 
Kubernetes 系 统 的 更 多 资料 ， 本 书 在 写作 期 间 也 从 这 些 参考 资料 中 获得 
了 很 大 的 帮助 。 


:Kubernetes Documentation 和 Kubernetes API Reference， 这 是 提供 


Kubernetes 领 域 相关 知识 最 全 面 、 最 深入 和 最 准确 的 参考 材料 。 
《Kubernetes in Action》， 本 书 的 谋 篇 布局 及 写作 理念 与 此 书 不 谋 


而 合 ， 因 此 笔者 在 本 书 中 对 许多 概念 的 理解 和 验证 也 以 此 书 为 素材 ， 并 
且 在 写作 之 时 有 多 处 概念 的 描述 也 借鉴 了 此 书 的 内 容 。 


:Red Hat Openshift Documentation，Red Hat 公 司 的 产品 文档 规范 、 
权威 、 细 致 且 条 理 清 晰 ， 是 不 可 多 得 的 参考 材料 。 


The New Stack 的 技术 文章 及 调研 报告 是 了 解 Kubernetes 系 统 技术 细 
节 和 行业 应 用 现状 及 趋势 的 不 可 多 得 的 优秀 资源 。 


"Bitnami 及 Heptio 站 点 上 的 博客 文章 提供 了 深入 了 解 和 学 习 
Kubernetes 系 统 东 个 特定 技术 细节 的 可 靠 资料 。 


为 外 ， 本 书 还 大 量 借鉴 了 通过 搜索 引擎 所 获取 到 的 不 少 技术 文章 和 
参考 文档 ， 在 这 里 一 并 向 这 些 书 籍 和 文章 的 作者 表示 深 深 的 谢意 ! 
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第 1 音 ”Kubernetes 系 统 基 础 


近 十 几 年 来 ，IT 领 域 新 技术 、 新 概念 层出不穷 ， 例 如 DevOps、 微 
服务 (Microservice) 、 容 器 (Container) 、 云 计算 (Cloud 
Computing) 和 区 块 链 (Blockchain) 等 ， 直 有 “ 乱 花 渐 欲 迷人 眼 ” 之 势 。 
另外 ， 出 于 业务 的 需要 ，IT 应 用 模型 也 在 不 断 地 变革 ， 例 如 ， 开 发 模式 
从 瀑布 式 〈Waterfall ) 到 敏捷 (Agile) 再 到 精益 〈Lean) ， 甚 至 是 与 
QA 和 Operations 融 合 的 DevOps， 应 用 程序 架构 从 单 体 (monolithic) 模 
型 到 分 层 模 型 再 到 微服 务 ， 部 署 及 打包 方式 从 面 癌 物理 机 到 虚拟 机 再 到 
容器 ， 应 用 程序 的 基础 架构 从 自 建 机 房 到 托管 再 到 云 计 算 ， 等 等 ， 这 些 
变革 使 得 IT 技术 应 用 的 效率 大 大 提升 ， 同 时 却 以 更 低 的 成 本 交付 更 高 质 


量 的 产品 。 


尤其 是 以 Docker 为 代表 的 容器 技术 的 出 现 ， 终 结 了 DevOps 中 交付 
和 部 署 环 节 因 环境 、 配 置 及 程序 本 和 丑 的 不 同 而 造成 的 动力 几 种 甚至 十 几 
种 部 团 配 置 的 困境 ， 将 它们 统一 在 容器 镜像 (image) 之 上 。 如 今 ， 越 
来 越 多 的 企业 或 组 织 开 始 选 择 以 镜像 文件 作为 交付 载体 。 容 器 镜像 之 内 
直接 包含 了 应 用 程序 及 其 依赖 的 系统 环境 、 库 、 基 础 程序 等 ， 从 而 能 够 
在 容器 引擎 上 直接 运行 。 于 是 ，IT 运 维 工 程 师 〈operator) 无 须 关 注 开 
发 应 用 程序 的 编程 语言 、 环 境 配置 等 ， 甚 至 连 业 务 逻 辑 本 号 也 不 必 过 多 
关注 ， 而 只 需要 掌握 容器 管理 的 单一 工具 链 即 可 。 


部 获 的 复杂 度 虽 然 降 低 了 ， 但 以 容器 格式 运行 的 应 用 程序 间 的 协同 
却 成 了 一 个 新 的 吸 答 解决 的 问题 ， 这 种 需求 在 微服 务 架构 中 表现 得 尤为 
明显 。 结 果 ， 以 Kubernetes 为 代表 的 容 需 编排 系统 应 需 而 生 。 




















1.1 容器 技术 概述 


容 右 是 一 种 轻 量 级 、 可 移植 、 自 包含 的 软件 打包 技术 ， 它 使 得 应 用 
程序 可 以 在 几乎 任何 地 方 以 相同 的 方式 运行 。 软 件 开 发 工程 师 在 目 己 笔 
记 本 上 创建 并 测试 完成 的 容器 ， 无 须 任何 修改 就 能 够 在 生产 系统 的 虚拟 
机 、 物 理 机 或 云 主机 上 运行 。 


容器 由 应 用 程序 本 身 和 它 的 环境 依赖 〈 库 和 其 他 应 用 程序 ) 两 部 分 
组 成 ， 并 在 宿主 机 (Host) 操作 系统 的 用 户 空间 中 运行 ， 但 与 操作 系统 
的 其 他 进程 互相 隔离 ， 它 们 的 实现 机 制 有 别 于 诸如 VMWare、KVM 和 和 
Xen 等 实现 方案 的 传统 虚拟 化 技术 。 容 器 与 虚拟 机 的 对 比 关 系 如 图 1-1 所 
人 No 
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图 1-1 容 堪 和 虚拟 机 对 比 


(http:/www.nuagenetworks.net/blog/containers/ ) 


由 于 同一 个 宿主 机 上 的 所 有 容器 部 共 至 其 确 层 操作 系统 内 核 空 





间 ) ， 这 束 使 得 容 右 在 体积 上 要 比 传统 的 虚拟 机 小 得 多 。 田 外， 局 动容 
虱 无 须 局 动 整个 操作 系统 ， 所 以 容 右 部 区 和 局 动 的 速度 更 快 ， 开 销 更 
小 ， 也 更 容易 迁移 。 事 实 上 ， 容 器 赋 予 了 应 用 程序 超 强 的 可 移植 能 


1.1.1 容 絮 技术 的 功用 


IT 系 统 在 架构 上 已经 迭代 数 十 年 之 入， 其 环境 复杂 程度 日 趋 加 重 ， 
直 有 积 重 难 返 之 势 。 现 如 今 ， 应 用 程序 开发 人 员 通 常 需 要 同时 使 用 多 种 
服务 构建 ， 并 要 架构 IT 信息 系统 ， 涉 及 MQ、Cache 和 DB 等 ， 且 很 可 能 
要 部 署 到 不 同 的 环境 中 ， 如 物理 服务 器 、 虚 拟 服 务 占 、 私 有 云 或 公有 云 
之 上 。 这 些 不 同 的 主机 或 许 还 有 着 不 同 的 系统 环境 ， 如 RHEL、Debian 
或 SUSE 等 Linux 发 行 版 ， 甚 至 是 UNIX、Windows 等 。 


结 末 ， 一 方面 应 用 程序 包含 了 多 种 服务 ， 每 种 服务 均 可 能 存在 依赖 
的 库 和 软件 包 ; 男 一 方面 存在 多 种 部 著 坏 境 ， 而 服务 在 运行 时 又 可 能 需 
要 动态 迁移 到 不 同 的 环境 中 。 于 是 ， 各 种 服务 和 环境 通过 排列 组 合 产生 
了 一 个 大 部 署 怎 阵 。 应 用 程序 开发 工程 师 在 编写 代码 时 需要 考虑 不 同 的 
运行 环境 ， 而 运 维 工程 师 则 需要 为 不 同 的 服务 和 平台 配置 环境 。 对 他 们 
双方 来 说 ， 这 都 必 将 是 一 项 困难 而 艰巨 的 任务 。 


六 运 的 是 ， 货 运 系 统 的 集装箱 机 制 为 解决 这 个 难题 提供 了 有 效 的 借 
监 方 案 。Docker 正 是 将 集装箱 思想 运用 到 软件 打包 上 ， 为 代码 提供 了 一 
个 基于 容器 的 标准 化 运输 系统 。Docker 可 以 将 几乎 任何 应 用 程序 及 其 依 
赖 的 运行 环境 都 打包 成 一 个 轻 量 级 、 可 移植 、 自 包含 的 容器 ， 并 能 够 运 
行 于 支持 Docker 容 器 引 敬 的 所 有 操作 系统 之 上 。 简 言 之 ， 容 器 的 优势 主 
要 表现 在 以 下 两 个 方面 。 


:应 用 程序 开发 工程 师 :“ 一 次 构建 ， 到 处 运行 ”(Build Once，Run 
Anywhere) 。 容 器 意味 着 环境 隔 房 和 可 重复 性 ， 开 发 人 员 只 需 为 应 用 创 
建 一 个 运行 环境 ， 并 将 其 打包 成 容器 便 可 在 各 种 部 署 环 境 上 运行 ， 并 与 
它 所 在 的 宿主 机 环境 隔离 。 


. 运 维 工程 师 : “一 次 配置 ， 运 行 所 有 ”(Configure Once，Run 
Anything) 。 一 且 配 置 好 标准 的 容器 运行 时 环境 ， 服 务 右 就 可 以 运行 任 
何 容 髓 ， 这 使 得 运 维 人 员 的 工作 变 得 更 高 效 、 一 致 和 可 重复 。 容 器 消除 
了 开发 、 测 试 、 生 产 环境 的 不 一 致 性 。 















































1.1.2 ”容器 简 史 


容器 技术 的 概念 最 初出 现在 2000 年 ， 当 时 称 为 FreeBSD jail， 这 种 
技术 可 将 FreeBSD 系 统 分 区 为 多 个 子 系统 《〈 也 称 为 Jail) 。2001 年 ， 通 过 
Jacques Gelinas 的 VServer 项 目 ， 隔 离 环境 的 实施 理念 进入 了 Linux 领 域 。 


Jail 的 目的 是 让 进程 在 经 过 修改 的 chroot 环 境 中 创建 ， 而 不 会 脱离 和 
影响 整个 系统 一 chroot 环 境 对 文件 系统 、 网 络 和 用 户 的 访问 都 实现 了 虚 
拟 化 。 然 而 ，Jail 在 实施 方面 存在 着 不 少 的 局 限 性 ， 当 它 与 Namespaces 
和 CGroups 等 技术 结合 在 一 起 之 后 ， 才 让 这 种 隔离 方法 从 构想 变 为 了 现 
实 。 后 来 ，Linux 容 器 项 目 (LXC) 又 为 其 添加 了 一 些 用 户 常 用 的 工 
有 具 、 模 板 、 库 和 语言 绑 定 ， 从 而 较 好 地 改善 了 用 户 使 用 容器 技术 时 的 体 


验 。 


Docker 在 LXC 项 目的 基础 上 ， 从 文件 系统 、 网 络 互 联 到 进程 隔离 等 
方面 对 容器 技术 进行 了 进一步 的 封装 ， 极 大 地 简化 了 容 右 的 创建 和 维护 
过 程 ， 从 而 促进 了 容器 技术 的 大 流行 。Docker 最 初 是 由 dotCloud 公 司 创 
始 人 Solomon Hykes 在 法 国 期 间 发 起 的 一 个 公司 内 部 项 目 ， 并 于 2013 年 3 
月 以 Apache 2.0 授 权 协 议 开 源 ， 其 项 目 代 码 托管 于 GitHub 之 上 。 虽 然 其 
最 初 的 实现 是 基于 LXC 项 目的 ， 但 Docker 在 后 来 的 0.7 版 本 转 为 使 用 自行 
开发 的 libcontainer 容 器 引擎 ， 而 1.11 版 本 又 将 其 换 作 了 runC 和 


containerd。 








@ 提示 。 在 2017 年 4 月 举行 的 DockerCon 上 ，Docker 公 司 将 
GitHub 上 原本 隶属 于 Docker 组 织 的 Docker 项 目 直 接 转 移 到 了 一 个 新 的 名 
为 Moby 的 组 织 下 ， 并 将 其 重 命 名 为 Moby 项 目 。 


1.1.3 ”Docker 的 功能 限制 


Docker 本 身 非 常 适 合用 于 管理 单个 容器 ， 不 过 ， 一 旦 开始 使 用 越 来 
越 多 的 容器 封装 和 运行 应 用 程序 ， 必 将 会 导致 其 管理 和 编排 变 得 越 来 越 
困难 。 最 终 ， 用 户 不 得 不 对 容器 实施 分 组 ， 以 便 跨 所 有 容 堪 提供 网 络 、 
监控 等 服务 。 于 是 ， 以 Kubernetes 为 代表 的 容器 编排 系统 应 运 而 





真正 的 生产 型 应 用 会 涉及 多 个 容器 ， 这 些 容器 必须 跨 多 个 服务 器 主 
机 进行 部 署 。Kubernetes 可 以 提供 所 需 的 编排 和 管理 功能 ， 以 便 用 户 针 
对 这 些 工作 负载 轻松 完成 大 规模 容 嚣 部署。 而且， 借助 于 Kubernetes 的 
编排 功能 ， 用 户 可 以 构建 出 跨 多 个 容 右 的 应 用 服务 ， 并 且 可 以 实现 跨 集 
群 调度 、 扩 展 容器 ， 以 及 长 期 持续 管理 这 些 容器 的 健康 状况 等 。 使 用 
中 ，Kubernetes 还 需要 与 网 络 、 存 储 、 安 全 性 、 监 控 及 其 他 服务 进行 整 
合 ， 以 提供 全 面 的 容器 基础 架构 ， 如 图 1-2 所 示 。 
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图 1-2 ” 容 右 与 容器 编排 《来 源 : RedHat Inc.) 


Kubernetes 利 用 容 右 的 扩 缩 容 机 制 解决 了 许多 常见 的 问题 ， 它 将 容 
器 归 类 到 一 起 ， 形 成 “容器 集 ”(Pod) ， 为 分 组 的 容器 增加 了 一 个 抽象 
层 ， 用 于 帮助 用 户 调度 工作 负载 (workload) ， 并 为 这 些 容 器 提供 所 需 
的 联网 和 存储 等 服务 。Kubernetes 的 其 他 部 分 可 帮助 用 户 在 这 些 Pod 之 间 
、 同时 确保 运行 正确 数量 的 容器 ， 以 充分 支持 实际 的 工作 
AD 





1.2 Kubernetes 概 述 


尽管 公开 面世 不 过 短 短 数 年 时 间 ，Kubernetes 业 已 成 为 容器 编排 领 
域 事实 上 的 标准 ， 其 近 一 两 年 的 发 展 状态 也 在 不 断 地 验证 着 Urs Hlzle 曾 
经 的 断言 : 无 论 是 公有 云 、 私 有 云 抑或 混合 云 ，Kubernetes 都 将 作为 一 
个 为 任何 应 用 、 任 何 环境 提供 的 容器 管理 框架 而 无 处 不 在 。 














1.2.1 ”Kubernetes 简 史 


Kubernetes〈 来 自 斋 腊 语 ， 意 为 "能手 ?或 "飞行 员 ”) 由 Joe Beda、 
Brendan Bums 和 Craig McLuckie 创 立 ， 而 后 Google 的 其 他 几 位 工程 师 ， 
包括 Brian Grant 和 Tim Hockin 等 加 盟 共同 研发 ， 并 由 Google 在 2014 年 首 
次 对 外 宣布 。Kubernetes 的 开发 和 设计 都 深 受 Google 内 部 系统 Borg 的 影 
啊 ， 事 实 上 ， 它 的 许多 顶级 贡献 者 之 前 也 是 Borg 系 统 的 开发 者 。 


Borg 是 Google 内 部 使 用 的 大 规模 集群 管理 系统 ， 久 负 感 名 。 它 建构 
于 容器 技术 之 上 ， 目 的 是 实现 资源 管理 的 自动 化 ， 以 及 路 多 个 数据 中 心 
的 资源 利用 率 最 大 化 。2015 年 4 月 ，Borg 论 文 《Large-scale cluster 
management at Google with Borg》 人 和 伴随 Kubernetes 的 高 调 宣传 被 Google 首 
次 公开 ， 人 们 终于 有 缘 得 颖 其 全 貌 。 


事实 上 ， 正 是 由 于 诞生 于 容 喜 世家 Google， 并 站 在 Borg 这 个 巨人 的 
肩膀 之 上 ， 充 分 受益 于 Borg 过 去 十 数 年 间 积累 的 经 验 和 教训 ， 
Kubernetes 表 一 面世 就 立即 广 受 关注 和 青睐 ， 并 迅速 称霸 了 容器 编排 技 
术 领 域 。 很 多 人 将 Kubernetes 视 为 Borg 系 统 的 一 个 开源 实现 版 本 ， 在 
Google 内 部 ，Kubernetes 的 原始 代号 曾经 是 Serven of Nine， 即 星际 迷航 
中 友好 的 “Borg” 角 色 ， 它 标识 中 的 舵 轮 有 七 个 轮 辐 就 是 对 该 项 目 代号 的 
致意 ， 如 图 1-3 所 示 。 











图 1-3 Kubernetes Logo 


Kubernetes v1.0 于 2015 年 7 月 21 日 发 布 ， 紧 随 其 后 ，Google 与 Linux 


基金 会 合作 组 建 了 Cloud Native Computing Foundation 〈 云 原生 计算 基金 
会 ， 简 称 为 CNCF) ， 并 将 Kubernetes 作 为 种 子 技术 予以 提供 。 这 之 后 ， 
Kubernetes 进 入 了 版 本 快速 迭代 期 ， 从 此 不 断 地 融入 着 新 功能 ， 如 
Federation、Network Policy API、RBAC、CRD 和 CSI， 等 等 ， 并 增加 了 
对 Windows 系 统 的 文 持 。 


2017 年 可 谓 是 容器 生态 发 展 史 上 具有 里 程 碑 意义 的 一 年 。 这 一 年 ， 
AWS、Azure 和 Alibaba Cloud 都 相继 在 其 原 有 容器 服务 上 新 增 了 对 
Kubernetes 的 支持 ， 而 Docker 官 方 也 在 2017 年 10 月 宣布 同时 支持 Swarm 
和 Kubernetes 编 排 系 统 。 这 一 年 ，RKT 容 器 派系 的 CoreOS 舍 弃 掉 自己 的 
调度 工具 Fleet， 将 其 商用 平台 Tectonic 的 重心 转移 至 Kubernetes。 这 一 
年 ， Mesos 也 于 9 月 宣布 了 对 Kubernetes 的 支持 ， 此 平 台 用 户 可 以 安装 、 
扩展 和 升级 多 个 生产 级 的 Kubernetes 和 集群 。 这 一 年 ，Rancher Labs 推 出 了 
其 2.0 版 本 的 容器 管理 平台 并 宣布 all-in Kubernetes， 放 弃 了 其 内 置 多 年 的 
容器 编排 系统 Cattle。 类 似 的 故事 依然 在 进行 ， 并 且 必 将 在 一 个 时 期 内 
持续 上 演 。 











1.2.2 ”Kubernetes 特 性 


Kubernetes 是 一 种 用 于 在 一 组 主机 上 运行 和 协同 容器 化 应 用 程序 的 
系统 ， 则 在 提供 可 预测 性 、 可 扩展 性 与 高 可 用 性 的 方法 来 完全 管理 容器 
化 应 用 程序 和 服务 的 生命 周期 的 平台 。 用 户 可 以 定义 应 用 程序 的 运行 方 
式 ， 以 及 与 其 他 应 用 程序 或 外 部 世界 交互 的 途径 ， 并 能 实现 服务 的 扩容 
和 缩 容 ， 执 行 平 滑 滚动 更 新 ， 以 及 在 不 同 版 本 的 应 用 程序 之 间 调 度 流 量 
以 测试 功能 或 回 滚 有 问题 的 部 署 。Kubernetes 提 供 了 接口 和 可 组 合 的 平 
台 原 语 ， 使 得 用 户 能够 以 高 度 的 灵活 性 和 可 靠 性 定义 及 管理 应 用 程序 。 
简单 总 结 起 来 ， 它 具有 以 下 几 个 重要 特性 。 


(1) 自动 装 箱 

建构 于 容器 之 上 ， 基 于 资源 依赖 及 其 他 约束 自动 完成 容器 部 署 旦 不 
影响 其 可 用 性 ， 并 通过 调度 机 制 混合 关键 型 应 用 和 非 关 键 型 应 用 的 工作 
负载 于 同一 节点 以 提升 资源 利用 率 。 

(2) 上 自我 修复 〈 上 自 念 ) 


支持 容 絮 故障 后 自动 重启 、 节 点 故障 后 重新 调度 容 费 ， 以 及 其 他 可 
用 节点 、 健 康 状 态 检查 失败 后 关闭 容器 并 重新 创建 等 目 我 修复 机 制 。 


(3) 水 平 扩展 


支持 通过 人 简单 命令 或 UI 手动 水 平 扩 展 ， 以 及 基于 CPU 等 资源 负载 率 
的 自动 水 平 扩展 机 制 。 

(4) 服务 发 现 和 负载 均衡 

Kubernetes 通 过 其 附加 组 件 之 一 的 KubeDNS (或 CoreDNS) 为 系统 
内 置 了 服务 发 现 功能 ， 它 会 为 每 个 Service 配 置 DNS 名 称 ， 并 人 允许 集群 内 
的 客户 端 直接 使 用 此 名 称 发 出 访问 请 求 ， 而 Service 则 通过 iptables 或 ipvs 
内 建 了 负载 均衡 机 制 。 


(5) 自动 发 布 和 回 深 

















Kubernetes 文 持 “ 灰 度 ” 更 新 应 用 程序 或 其 配置 信息 ， 它 会 监控 更 新 
过 程 中 应 用 程序 的 健康 状态 ， 以 确保 它 不 会 在 同一 时 刻 杀 挥 所 有 实例 ， 
而 此 过 程 中 一 旦 有 故障 发 生 ， 就 会 立即 自动 执行 回 滚 操作 。 


(6) 密 钥 和 配置 管理 


Kubernetes 的 ConfigMap 实 现 了 配置 数据 与 Docker 镜 像 解 厢 ， 需 要 
时 ， 仅 对 配置 做 出 变更 而 无 须 重新 构建 Docker 锐 像 ， 这 为 应 用 开发 部 署 
带 来 了 很 大 的 灵活 性 。 此 外 ， 对 于 应 用 所 依赖 的 一 些 敏感 数据 ， 如 用 户 
名 和 密码 、 令 牌 、 密 钥 等 信息 ，Kubernetes 专 门 提 供 了 Secret 对 象 为 其 解 
耘 ， 既 便利 了 应 用 的 快速 开发 和 交付 ， 又 提供 了 一 定 程度 上 的 安全 保 


障 。 








(7) 存储 编排 


Kubernetes 文 持 Pod 对 象 按 需 上 自动 挂 载 不 同类 型 的 存储 系统 ， 这 包括 
节点 本 地 存储 、 公 有 云 服 务 商 的 云 存储 (如 AWS 和 GCP 等 ) ， 以 及 网 络 
存储 系统 (例如 ，NFS、iSCSI、GlusterFS、Ceph、Cinder 和 Flocker 
A 


(8) 批量 处 理 执行 


除了 服务 型 应 用 ，Kubernetes 还 支持 批 处 理 作 业 及 CI( 持 续集 
成 ) ， 如 果 需 要 ， 一 样 可 以 实现 容 右 故障 后 恢复 。 





1.2.3 Kubernetes 概 念 和 术语 


Kubernetes 使 用 共享 网 络 将 多 个 物理 机 或 虚拟 机 汇集 到 一 个 集群 
中 ， 在 各 服务 器 之 间 进 行 通 信 ， 该 集群 是 配置 Kubernetes 的 所 有 组 件 、 
功能 和 工作 负载 的 物理 平台 。 集 群 中 一 台 服 务 器 《或 高 可 用 部 署 中 的 一 
组 服务 器 ) 用 作 Master， 负 责 管 理 整个 集群 ， 余 下 的 其 他 机 器 用 作 
Worker Node 〈 早 期 版 本 中 也 称 为 Minion) ， 它 们 是 使 用 本 地 和 外 部 资 
源 接收 和 运行 工作 负载 的 服务 器 ， 如 图 1- 4 所 示 。 集群 中 的 这 些 主机 可 
以 是 物理 服务 器 ， 也 可 以 是 虚拟 机 (包括 JaaS 云 端的 VPS) 。 
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图 1-4 Kubernetes 集 群 主机 
(1) Master 


Master 是 集群 的 网 关 和 中 酌 ， 负 责 诸如 为 用 户 和 客户 端 暴 露 API、 
跟踪 其 他 服务 器 的 健康 状态 、 以 最 优 方式 调度 工作 负载 ， 以 及 编排 其 他 
组 件 之 间 的 通信 等 任务 ， 它 是 用 户 或 客户 端 与 集群 之 间 的 核心 联络 点 ， 
并 负责 Kubernetes 系 统 的 大 多 数 集 中 式 管 控 罗 辑 。 单 个 Master 节 点 即 可 
完成 其 所 有 的 功能 ， 但 出 于 见 余 及 负载 均衡 等 目的 ， 生 产 环 境 中 通常 需 
要 协同 部 署 多 个 此 类 主机 。Master 节 点 类 似 于 蜂 群 中 的 蜂王 。 


(2) Node 


Node 是 Kubernetes 集 群 的 工作 节点 ， 负 责 接 收 来 自 Master 的 工作 指 
令 并 根据 指 0 各 Pod 对 象 ， 以 及 调整 网 络 规则 以 合理 地 
路 由 和 转发 流量 等 论 上 讲 ，Node 可 以 是 任何 形式 的 计算 设备 ， 不 过 
Master 会 统一 0 Node 类 似 于 蜂 群 中 的 工 
蜂 ， 和 生产 环 境 中 ， 它 们 通常 数量 众多 。 


Kubernetes 将 所 有 Node 的 资源 集结 于 一 处 形成 一 台 更 加 强大 的 “服务 
器 ”， 如 图 1-5 所 示 ， 在 用 户 将 应 用 部 署 于 其 上 时 ，Master 会 使 用 调度 算 
法 将 其 自动 指派 至 某 个 特定 的 Node 运 行 。 在 Node 加 入 集群 或 从 集群 中 
移 除 时 ，Master 也 会 按 需 重新 编排 影响 到 的 Pod〈 容 器 ) 。 于 是 ， 用 户 
无 须 关 心 其 应 用 究竟 运行 于 何 处 。 
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图 1-5” Node 组 成 的 虚拟 资源 池 


从 抽象 的 视角 来 讨 ，Kubernetes 还 有 着 众多 的 组 件 来 支撑 其 内 部 的 
业务 逻辑 ， 包 插 运 行 应 用 、 应 用 编排 、 服 务 暴 露 、 应 用 恢复 等 ， 它 们 在 
Kubernetes 中 被 抽象 为 Pod、Service、Controller 等 资源 类 型 ， 下 面 列 出 
了 几 个 较为 常用 的 资源 抽象 。 





(1) Pod 


Kubernetes 并 不 直接 运行 容器 ， 而 是 使 用 一 个 抽象 的 资源 对 象 来 封 
装 一 个 或 者 多 个 容器 ， 这 个 抽象 即 为 Pod， 它 也 是 Kubernetes 的 最 小 调度 
单元 。 同 一 Pod 中 的 容器 共享 网 络 名 称 空间 和 存储 资源 ， 这 些 容 器 可 经 
由 本 地 回环 节 口 lo 直接 通信 ， 但 彼此 之 间 又 在 Mount、User 及 PID 等 名 称 
空间 上 保持 了 隔离 。 尽 管 Pod 中 可 以 包含 多 个 容器 ， 但 是 作为 最 小 调度 
单元 ， 它 应 该 尽 可 能 地 保持 “小 >”， 即 通常 只 应 该 包含 一 个 主 容器 ， 以 及 
必要 的 辅助 型 容器 (sidecar) ， 如 图 1-6 所 示 。 
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图 1-6 ”Kubemetes Pod 示 意图 


(2) 资源 标签 


标签 (Label) 是 将 资源 进行 分 类 的 标识 符 ， 资 源 标签 其 实 承 是 一 
个 键 值 型 (key/values 数据 。 标 俭 旨 在 指定 对 象 〈 如 Pod 等 ) 辨识 性 的 
属性 ， 这 些 属 性 仅 对 用 户 存 在 特定 的 意义 ， 对 Kubernetes 集 群 来 说 并 不 
直接 表达 核心 系统 语义 。 标 签 可 以 在 对 象 创建 时 附加 其 上 ， 并 能 够 在 创 
建 后 的 任意 时 间 进 行 添加 和 修改 。 一 个 对 象 可 以 拥有 多 个 标签 ， 一 个 标 
签 也 可 以 附加 于 多 个 对 象 ( 通 常 是 同一 类 对 象 ) 之 上 ， 如 图 1-7 所 示 。 
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release: beta release: canary 


env: production env: production 


role: frontend role: backend 





图 1-7 ”Kubernetes 资 源 标签 
(3) 标签 选择 器 


标签 选择 器 (Selector) 全 称 为 “Label Selector”， 它 是 一 种 根据 
Label 来 过 小 符 合 条 件 的 资源 对 象 的 机 制 。 例 如 ， 将 附 有 标签 “Tole: 
backend” 的 所 有 Pod 对 象 挑选 出 来 归 为 一 组 就 是 标签 选择 器 的 一 种 应 
用 ， 如 图 1-8 所 示 。 用 户 通 常 使 用 标签 对 资源 对 象 进行 分 类 ， 而 后 使 用 
标签 选择 器 挑选 出 它们 ， 例 如 将 其 创建 为 某 Service 的 端点 。 








role: backend 


















label 
selector 


matchLables: 
role: backend 








role: backend 








role: backend 
图 1-8 ”标签 选择 器 

(4) Pod 控 制 器 

尽管 Pod 是 Kubernetes 的 最 小 调度 单元 ， 但 用 户 通常 并 不 会 直接 部 署 


管理 Pod 对 象 ， 而 是 要 借助 于 男 一 类 抽象 一 控制 占 (Controller〉 对 其 
行 


及 
进行 管理 。 用 于 工作 负载 的 控制 器 是 一 种 管理 Pod 生 命 周 期 的 资源 抽 


象 ， 它 们 是 Kubernetes 上 的 一 类 对 象 ， 而 非 单个 资源 对 象 ， 包 括 
ReplicationController、ReplicaSet、Deployment、StatefulSet、Job 等 。 以 
图 1-9 中 所 示 的 Deployment 控 制 右 为 例 ， 它 负责 确保 指定 的 Pod 对 象 的 副 
本 数量 精确 符合 定义 ， 否 则 “多 退 少 补 ”。 使 用 控制 吉之 后 就 不 再 需要 手 
动 省 理 Pod 对 象 了 ， 用 户 只 需要 声明 应 用 的 期 望 状态 ， 控 制 占 就 会 自动 
对 其 进行 进程 管理 。 
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图 1-9 ” Deployment 控制 器 示意 图 
(5) 服务 资源 (Service) 


Service 是 建立 在 一 组 Pod 对 象 之 上 的 资源 抽象 ， 它 通过 标签 选择 器 
选 定 一 组 Pod 对 象 ， 并 为 这 组 Pod 对 象 定 义 一 个 统一 的 固定 访问 入 口 ( 通 
常 是 一 个 IP 地 址 ) ， 知 Kubernetes 集 群 存在 DNS 附件 ， 它 就 会 在 Service 
创建 时 为 其 自动 配置 一 个 DNS 名 称 以 便 客 户 端 进行 服务 发 现 。 到 达 
Service IP 的 请 求 将 被 负载 均衡 至 其 后 的 端点 一 各 个 Pod 对 象 之 上 ， 因 此 
Service 从 本 质 上 来 讲 是 一 个 四 层 代 理 服 务 。 男 外 ，Service 还 可 以 将 集群 
外 部 流量 引入 到 集群 中 来 。 


(6) 存储 卷 


存储 卷 Volume) 是 独立 于 容器 文件 系统 之 外 的 存储 空间 ， 常 用 
于 扩展 容器 的 存储 空间 并 为 它 提供 持久 存储 能 力 。Kubernetes 集 群 上 的 
存储 卷 大 体 可 分 为 临时 卷 、 本 地 卷 和 网 络 卷 。 临 时 卷 和 本 地 卷 都 位 于 
Node 本 地 ， 一 旦 Pod 被 调度 至 其 他 Node， 此 种 类 型 的 存储 卷 将 无 法 访问 
到 ， 因 此 临时 卷 和 本 地 卷 通 常用 于 数据 缓存 ， 持 久 化 的 数据 则 需要 放置 











于 持久 卷 (persistent volume) 之 上 。 
(7) Name 和 Namespace 


名 称 (Name) 是 Kubemetes 集 群 中 资源 对 象 的 标识 符 ， 它 们 的 作用 
域 通常 是 名 称 空间 (Namespace) ， 因 此 名 称 空间 是 名 称 的 额外 的 限定 
机 制 。 在 同一 个 名 称 空间 中 ， 同 一 类 型 资源 对 象 的 名 称 必须 具有 唯一 
性 。 名 称 空间 通常 用 于 实现 租户 或 项 目的 资源 隔离 ， 从 而 形成 逻辑 分 
组 ， 如 图 1-10 所 示 。 创 建 的 pod 和 Service 等 资源 对 象 都 属于 名 称 空间 级 
别 ， 未 指定 时 ， 它 们 都 属于 默认 的 名 称 空间 “default”。 
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图 1-10 ”名 称 空间 








(8) Annotation 


Annotation 注解) 是 男 一 种 附加 在 对 象 之 上 的 键 值 类 型 的 数据 ， 

但 它 拥 有 更 大 的 数据 容量 。Annotation 常 用 于 将 各 种 非 标 识 型 元 数据 
(metadata) 附 加 到 对 象 上 ， 但 它 不 能 用 于 标识 和 选择 对 象 ， 通 常 也 不 
会 被 Kubernetes 直 接 使 用 ， 其 主要 目的 是 方便 工具 或 用 户 的 阅读 及 查找 





(9) Ingress 


Kubernetes 将 Pod 对 象 和 外 部 网 络 环境 进行 了 隔离 ，Pod 和 Service 等 
对 象 间 的 通信 都 使 用 其 内 部 专用 地 址 进行 ， 如 若 需 要 开放 某 些 Pod 对 象 
提供 给 外 部 用 户 访问 ， 则 需要 为 其 请 求 流量 打开 一 个 通 往 Kubernetes 集 
群 内 部 的 通道 ， 除 了 Service 之 外 ，Ingress 也 是 这 类 通道 的 实现 方式 之 


1.3 Kubernetes 集 群 组 件 


一 个 典型 的 Kubernetes 集 群 由 多 个 工作 节点 (workernode) 和 一 个 
集群 控制 平面 (control plane， 即 Master) ， 以 及 一 个 集群 状态 存储 系统 
Cetcd) 组 成 。 其 中 Master 节 点 负责 整个 集群 的 管理 工作 ， 为 集群 提供 
管理 接口 ， 并 监控 和 编排 集群 中 的 各 个 工作 节点 。 各 节点 负责 以 Pod 的 
形式 运行 容器 ， 因 此 ， 各 节点 需要 事先 配置 好 容器 运行 依赖 到 的 所 有 服 
务 和 资源 ， 如 容器 运行 时 环境 等 。Kubernetes 的 系统 架构 如 图 1-11 所 
示 。 

















Master 节 点 主要 由 apiserver、controller-manager 和 scheduler 三 个 组 
件 ， 以 及 一 个 用 于 集群 状态 存储 的 etcd 存 储 服务 组 成 ， 而 每 个 Node 节 点 
则 主要 包含 kubelet、kube-proxy 及 容器 引擎 (Docker 是 最 为 党 用 的 实 
现 ) 等 组 件 。 此 外 ， 完 整 的 集群 服务 还 依赖 于 一 些 附加 组 件 ， 如 
KubeDNS 等 。 


1.3.1 Master 组 件 


Kubernetes 的 集群 控制 平面 由 多 个 组 件 组 成 ， 这 些 组 件 可 统一 运行 
于 单一 Master 节 点 ， 也 可 以 以 多 副本 的 方式 同时 运行 于 多 个 节点 ， 以 为 
Master 提 供 高 可 用 功能 ， 甚 至 还 可 以 运行 于 Kubernetes 集 群 目 身 之 上 。 
Master 主 要 包含 以 下 几 个 组 件 。 
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图 1-11 Kubernetes 系 统 组 件 








(1) API Server 


API Server 负 责 输出 RESTfu 风 格 的 Kubernetes API， 它 是 发 往 集群 
的 所 有 REST 操 作 命令 的 接 入 点 ， 并 负责 接收 、 校 验 并 响应 所 有 的 REST 
请 求 ， 结 果 状 态 被 持久 存储 于 etcd 中 。 因 此 ，API Server 是 整个 集群 的 网 
关 。 


(2) 集群 状态 存储 (Cluster State Store) 


Kubernetes 集 群 的 所 有 状态 信息 都 需要 持久 存储 于 存储 系统 etcd 
中 ， 不 过 ，etcd 是 由 CoreOS 基 于 Raft 协 议 开 发 的 分 布 式 键 值 存储 ， 可 用 
于 服务 发 现 、 共 享 配 置 以 及 一 致 性 保障 〈 如 数据 库 主 节点 选择 、 分 布 式 
锁 等 ) 。 因 此 ，etcd 是 独立 的 服务 组 件 ， 并 不 隶属 于 Kubernetes 集 群 自 
有 身 。 生 产 环 境 中 应 该 以 etcd 集 群 的 方式 运行 以 确保 其 服务 可 用 性 。 


etcd 不 仅 能 够 提供 键 值 数据 存储 ， 而 且 还 为 其 提供 了 监听 (watch ) 
机 制 ， 用 于 监听 和 推送 变更 。Kubernetes 集 群 系统 中 ，etcd 中 的 键 值 发 
生变 化 时 会 通知 到 API Server， 并 由 其 通过 watch API 回 客户 端 输出 。 基 
于 watch 机 制 ，Kubernetes 集 群 的 各 组 件 实现 了 高 效 协同 。 


(3) 控制 右 管 理 器 (Controller Manager) 


Kubernetes 中 ， 集 群 级 别 的 大 多 数 功能 都 是 由 几 个 被 称 为 控制 器 的 
进程 执行 实现 的 ， 这 几 个 进程 被 集成 于 kube-controller-manager 守 护 进 程 
由 控制 器 完成 的 功能 主要 包括 生命 周期 功能 和 API 业 务 逻 辑 ， 具 体 

Bs 


生命 周期 功能 :包括 Namespace 创 建 和 生命 周期 、Event 垃 圾 回 
收 、Pod 终 止 相关 的 垃圾 回收 、 级 联 垃圾 回收 及 Node 垃 圾 回收 等 。 


API 业务 逻辑 : 例如 ， 由 ReplicaSet 执 行 的 Pod 扩 展 等 。 
(4) 调度 器 (Scheduler) 


Kubernetes 是 用 于 部 署 和 管理 大 规模 容器 应 用 的 平台 ， 根 据 集 群 规 
模 的 不 同 ， 其 托管 运行 的 容器 很 可 能 会 数 以 和 干 计 甚至 更 多 。API Server 
确认 Pod 对 象 的 创建 请 求 之 后 ， 便 需要 由 Scheduler 根 据 集群 内 各 节点 的 
可 用 资源 状态 ， 以 及 要 运行 的 容器 的 资源 需求 做 出 调度 决策 ， 其 工作 逻 
辑 如 图 1-12 所 示 。 另 外 ，Kubernetes 还 支持 用 户 自 定义 调度 器 。 
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图 1-12 “Kubernetes 调 度 器 


1.3.2 ”Node 组 件 


Node 人 负 员 提供 运行 容 占 的 各 种 依赖 环境 ， 并 接受 Master 的 管理 。 
个 Node 主 要 由 以 下 几 个 组 件 构成 。 


(1) Node 的 核心 代理 程序 kubelet 


kubelet 是 运行 于 工作 节点 之 上 的 守护 进程 ， 它 从 API Server 接 收 关 
于 Pod 对 象 的 配置 信息 并 确保 它们 处 于 期 望 的 状态 (desired state， 后 文 
不 加 区 别 地 称 之 为 “目标 状态 ”) 。kubelet 会 在 API Server 上 注册 当前 工 
作 节 点 ， 定 期 加 Master 汇 报 节点 资源 使 用 情况 ， 并 通过 cAdvisor 监 控 容 
器 和 节点 的 资源 占用 状况 。 


(2) 容 吉 运 行 时 环境 











每 个 Node 都 要 提供 一 个 容器 运行 时 (Container Runtime) 环境 ， 它 
负责 下 载 镜像 并 运行 容器 。kubelet 并 未 固定 链接 至 某 容 器 运行 时 环境 ， 
而 是 以 插件 的 方式 载 入 配置 的 容器 环境 。 这 种 方式 清晰 地 定义 了 各 组 件 
的 边界 。 目 前 ，Kubernetes 支 持 的 容器 运行 环境 至 少 包 括 Docker、 
RKT、cri-o 和 Fraki 等 。 





(3) kube-proxy 





每 个 工作 节点 都 需要 运行 一 个 kube-proxy 守 护 进程 ， 它 能 够 按 需 为 
Service 资 源 对 象 生 成 iptables 或 ipvs 规 则 ， 从 而 捕获 访问 当前 Service 的 
ClusterIP 的 流量 并 将 其 转发 至 正确 的 后 端 Pod 对 象 。 


1.3.3 ”核心 附件 


Kubernetes 集 群 还 依赖 于 一 组 称 为 “附件 ”(add-ons) 的 组 件 以 提供 
完整 的 功能 ， 它 们 通常 是 由 第 三 方 提供 的 特定 应 用 程序 ， 且 托管 运行 于 
Kubernetes 集 群 之 上 ， 如 图 1-11 所 示 。 下 面 列 出 的 几 个 附件 各 目 为 集群 
从 不 同 角度 引用 了 所 需 的 核心 功能 。 


.KubeDNS: 在 Kubernetes 集 群 中 调度 运行 提供 DNS 服务 的 Pod， 同 
一 集群 中 的 其 他 Pod 可 使 用 此 DNS 服务 解雇 主机 名 。Kubernetes 目 1.11 版 
本 开始 默认 使 用 CoreDNS 项 目 为 集群 提供 服务 注册 和 服务 发 现 的 动态 名 
之 前 的 版 本 中 用 到 的 是 kube-dns 项 目 ， 而 SkyDNS 则 是 更 
一 代 的 项 目 。 


:Kubernetes Dashboard: Kubernetes 集 群 的 全 部 功能 都 要 基于 Web 的 
UI， 来 管理 集群 中 的 应 用 甚至 是 集群 自身 。 


:Heapster: 容器 和 节点 的 性 能 监控 与 分 析 系 统 ， 它 收集 并 解析 多 种 
指标 数据 ， 如 资源 利用 率 、 和 生命 周期 事件 等 。 新 版 本 的 Kubernetes 中 ， 
其 功能 会 逐渐 由 Prometheus 结 合 其 他 组 件 所 取代 。 


-Ingress Controller: Service 是 一 种 工作 于 传统 层 的 负载 均衡 器 ， 而 
Ingress 是 在 应 用 层 实现 的 HTTP 〈s) 负载 均衡 机 制 。 不 过 ，Ingress 资 源 
自身 并 不 能 进行 < 流量 穿 透 *， 它 仅 是 一 组 路 由 规则 的 集合 ， 这 些 规则 需 
要 通过 Ingress 控 制 器 〈Ingress Controller) 发 挥 作 用 。 目 前 ， 此 类 的 可 用 
项 目 有 Nginx、Traefik、Envoy 及 HAProxy 等 。 














1.4 Kubernetes 网 络 模型 基础 


云 计 算 的 核心 是 虚拟 化 技术 ， 网 络 虚 拟 化 技术 又 是 其 最 重要 的 组 成 
部 分 ， 用 于 在 物理 网 络 上 虚拟 多 个 相互 隔离 的 虚拟 网 络 ， 实 现 网 络 资源 
切片 ， 提 高 网 络 资源 利用 率 ， 实 现 弹 性 化 网 络 。Kubernetes 作 为 容器 云 
技术 栈 中 的 容 喜 编排 组 件 ， 必 然 需 要 在 多 租户 《名 称 空间 ) 的 基础 上 实 
现 弹性 网 络 管理 ， 这 也 是 “基础 设施 即 代 码 ” 的 要 求 之 一 。 





1.4.1 网 络 模型 概述 


Kubernetes 的 网 络 中 主要 存在 四 种 类 型 的 通信 : 同一 Pod 内 的 容器 间 
通信 、 各 Pod 彼 此 之 间 的 通信 、Pod 与 Service 间 的 通信 ， 以 及 集群 外 部 的 
流量 同 Service 之 间 的 通信 。Kubernetes 为 Pod 和 Service 资 源 对 象 分 别 使 用 
了 各 自 的 专用 网 络 ，Pod 网 络 由 Kubernetes 的 网 络 插件 配置 实现 ， 而 
Service 的 网 络 则 由 Kubernetes 和 集群 予以 指定 。 为 了 提供 更 灵活 的 解决 方 
式 ，Kubernetes 的 网 络 模型 需要 借助 于 外 部 插件 实现 ， 它 要 求 任 何 实现 
机 制 都 必须 满足 以 下 需求 。 


:所 有 Pod 间 均 可 不 经 NAT 机 制 而 直接 通信 。 
.所 有 节点 均 可 不 经 NAT 机 制 而 直接 与 所 有 容器 通信 。 


' 容 露 目 己 使 用 的 下 也 是 其 他 容器 或 节点 直接 看 到 的 地 址 。 换 句 话 
象 都 位 于 同一 平面 网 络 中 ， 而 且 可 以 使 用 Pod 上 自身 的 地 址 
关 通 信 。 


Kubernetes 使 用 的 网 络 插件 必须 能 为 Pod 提 供 满 足以 上 要 求 的 网 络 ， 
它 需 要 为 每 个 Pod 配 置 至 少 一 个 特定 的 地 址 ， 即 Pod IP。Pod 了 地 址 实际 
存在 于 某 个 网 卡 〈 可 以 是 虚拟 设备 ) 上 ， 而 Service 的 地 址 却 是 一 个 虚拟 
PP 地 址 ， 没 有 任何 网 络 接口 配置 此 地 址 ， 它 由 kube-proxy 借 助 iptables 规 
则 或 ijpvs 规 则 重新 定向 到 本 地 端口 ， 再 将 其 调度 至 后 端 Pod 对 象 。 

Service 的 IP 地 址 是 集群 提供 服务 的 接口 ， 也 称 为 Cluster IP。 


Pod 网 络 及 其 IP 由 Kubernetes 的 网 络 插件 负责 配置 和 管理 ， 具 体 使 用 
的 网 络 地 址 可 在 管理 配置 网 络 插件 时 指定 ， 如 10.244.0.0/16 网 络 。 而 
Cluster 网 络 和 IP 则 是 由 Kubernetes 集 群 负 责 配 置 和 管理 ， 如 10.96.0.0/12 
网 络 。 


总 结 起 来 ，Kubernetes 集 群 至 少 应 该 包含 三 个 网 络 ， 如 图 1-13 中 的 
网 络 环境 所 示 。 一 个 是 各 主机 (Master、Node 和 etcd 等 ) 自身 所 属 的 网 
络 ， 其 地 址 配置 于 主机 的 网 络 接口 ， 用 于 各 主机 之 间 的 通信 ， 例 如 ， 
Master 与 各 Node 之 间 的 通信 。 此 地 址 配置 于 Kubernetes 集 群 构建 之 前 ， 
它 并 不 能 由 Kubernetes 管 理 ， 管 理 员 需要 于 集群 构建 之 前 自行 确定 其 地 
址 配置 及 管理 方式 。 第 二 个 是 Kubernetes 集 群 上 专用 于 Pod 资 源 对 象 的 网 

















络 ， 它 是 一 个 虚拟 网 络 ， 用 于 为 各 Pod 对 象 设 定 卫 地 址 等 网 络 参数 ， 其 
地 址 配置 于 Pod 中 容器 的 网 络 接 口 之 上 。Pod 网 络 需 要 借助 kubenet 插 件 
或 CNI 插 件 实现 ， 该 插件 可 独立 部 署 于 Kubernetes 集 群 之 外 ， 亦 可 托管 
于 Kubernetes 之 上 ， 它 需要 在 构建 Kubernetes 集 群 时 由 管理 员 进 行 定 义 ， 
而 后 在 创建 Pod 对 象 时 由 其 上 自动 完成 各 网 络 参数 的 动态 配置 。 第 三 个 是 
专用 于 Service 资 源 对 象 的 网 络 ， 它 也 是 一 个 虚拟 网 络 ， 用 于 为 
Kubernetes 集 群 之 中 的 Service 配 置 IP 地 址 ， 但 此 地 址 并 不 配置 于 任何 主 
机 或 容 右 的 网 络 接 口 之 上 ， 而 是 通过 Node 之 上 的 kube-proxy 配 置 为 
iptables 或 ipvs 规 则 ， 从 而 将 发 往 此 地 址 的 所 有 流量 调度 至 其 后 端的 各 
Pod 对 象 之 上 。Service 网 络 在 Kubernetes 集 群 创 建 时 予以 指定 ， 而 各 
Service 的 地 址 则 在 用 户 创建 Service 时 予以 动态 配置 。 
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六 点 网 络 


图 1-13 ”Kubernetes 网 络 环境 


名 提示 。 “CNI 是 指 容器 网 络 接口 (Container Network 
Interface) ， 是 由 CNCF (Cloud Native Computing Foundation)〉 维护 的 项 
目 ， 其 由 一 系列 的 用 于 编写 配置 容器 网 络 插件 的 规范 和 库 接 口 
(libcni) 组 成 ， 文 持 众 多 插件 项 目 。 后 文 对 此 有 详细 说 明 。 


1.4.2 ”集群 上 的 网 络 通信 


Kubernetes 集 群 的 客户 端 大 体 可 以 分 为 两 类 : API Server 客 户 端 和 应 
用 程序 《运行 为 Pod 中 的 容器 ) 客户 端 ， 如 图 1-14 所 示 。 第 一 类 客户 端 
通常 包含 人 类 用 户 和 Pod 对 象 两 种 ， 它们 通过 API Server 访 问 Kubernetes 
集群 完成 管理 任务 ， 例 如 ， 管 理 集群 上 的 各 种 资源 对 象 。 第 二 类 客户 端 
一 般 也 包含 人 类 用 户 和 Po4 对 象 两 种 ， 它们 的 访问 目标 是 Pod 上 运行 于 容 
器 中 的 应 用 程序 提供 的 各 种 具体 的 服务 ， 如 redis 或 nginx 等 ， 个 迪 本 这 
些 访问 请 求 通常 要 经 由 Service 或 Ingress 资 源 对 象 进行 。 再 外， 帅 二 和 
mL 目标 对 象 的 操作 要 经 由 第 一 类 客户 端 创建 和 配置 完成 后 才能 
进行 。 
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图 1-14 ”Kubernetes 窒 户 端 及 其 类 型 


访问 API Server 时 ， 人 类 用 户 一 般 借助 于 命令 行 工 具 kubectl 或 图 形 
UI 例如 Kubernetes Dashboard) 进行 ， 也 可 通过 编程 接口 进行 访问 ， 包 
括 REST API。 访 问 Pod 中 的 应 用 时 ， ee 用 
程序 ， 例 如 ， 对 于 运行 Nginx 容 器 的 Pod 来 说 ， 其 最 常用 工具 自然 是 浏览 
同 。 





管理 员 〈 开 发 人 员 或 运 维 人 员 ) 使 用 Kubernetes 和 集群 的 常见 操作 包 
括 通过 控制 器 创建 Pod， 在 Pod 的 基础 上 创建 Service 供 第 二 类 客户 端 访 


问 ， 更 新 Pod 中 的 应 用 版 本 (更 新 和 回 深 ) 以 及 对 应 用 规模 进行 扩容 或 
缩 容 等 ， 另 外 还 有 集群 附件 管理 、 存 储 卷 管理 、 网 络 及 网 络 策略 管理 、 
资源 管理 和 安全 管理 等 ， 这 些 内 容 将 在 后 面 的 章节 中 展开 。 不 过 ， 这 一 
切 的 前 提 是 要 先 构建 出 一 个 可 用 的 Kubernetes 人 集群 ， 这 一 内 容 将 在 第 2 章 
中 着 重 讲述 。 





1.5 本章 小 结 


本 章 介 绍 了 Kubernetes 的 历史 、 功 用 、 特 性 及 其 相关 的 核心 概述 和 
术语 ， 并 简单 接 述 了 其 架构 及 其 各 关键 组 件 ， 以 及 集群 网 络 中 的 常见 通 
信访 3Q 二 体 如 下 


.Kubernetes 集 群 主要 由 Master 和 Node 两 类 节点 组 成 。 


“Master 主 要 包含 API Server、controller-manager、Scheduler 和 etcd 几 
个 组 件 ， 其 中 API Server 是 整个 集群 的 网 关 。 


:Node 主 要 由 kubelet、kube-proxy 和 容器 引 苟 等 组 件 构成 ，kubelet 是 
Kubernetes 集 群 的 工作 于 节点 之 上 的 代理 组 件 。 


完整 的 Kubernetes 集 群 还 需要 部 署 有 CoreDNS (或 KubeDNS) 、 
Prometheus 〈 或 HeapSter) 、Dashboard 和 Ingress Controller 几 个 附加 组 
件 。 


Kubernetes 的 网 络 中 主要 存在 四 种 类 型 的 通信 : 同一 Pod 内 的 容器 
间 通 信 、 各 Pod 间 的 通信 、Pod 与 Service 间 的 通信 ， 以 及 集群 外 部 的 流量 
同 Service 之 间 的 通信 。 


第 2 章 ”Kubernetes 快 速 入 门 


Kubernetes 集 群 将 所 有 节点 上 的 资源 都 整合 到 一 个 大 的 虚拟 资源 池 
里 ， 以 代替 一 个 个 单独 的 服务 器 ， 而 后 开放 诸如 CPU、 内 存 和 IO 这 些 
基本 资源 用 于 运行 其 基本 单元 一 Pod 资 源 对 象 。Pod 的 容器 中 运行 着 隔离 
的 任务 单元 ， 它 们 以 Pod 为 原子 单位 ， 并 根据 其 资源 需求 从 虚拟 资源 池 
中 为 其 动态 分 配 资源 。 吞 可 以 将 整个 集群 类 比 为 一 台 传 统 的 服务 占 ， 那 
么 Kubernetes (Master) 束 好 比 是 操作 系统 内 核 ， 其 主要 职责 在 于 抽象 
资源 并 调度 任务 ， 而 Pod 资 源 对 象 束 是 那些 运行 于 用 户 空间 中 的 进程 。 
于 是 ， 传 统 意义 上 的 向 单 节点 或 集群 直接 部 署 、 配 置 应 用 的 模型 日 渐 式 
微 ， 取 而 代 之 的 是 癌 Kubernetes 的 API Server 提 交 运 行 Pod 对 象 。 


API Server 是 负责 接收 并 啊 应 客户 端 提 交 任 务 的 接口 ， 用 户 可 使 用 
诸如 CLI 工 具 〈 如 kubectt) 、UI 工 具 〈 如 Dashboard) 或 程序 代码 (客户 
端 开 发 库 ) 发 起 请 求 ， 其 中 ，kubectl 是 最 为 常用 的 交互 式 命令 行 工具 。 
快速 了 解 Kubernetes 的 办 法 之 一 惑 是 部 署 一 个 测试 集群 ， 并 演 试 测试 使 
用 它 的 各 项 基本 功能 。 本 章 在 简单 介绍 核心 资源 对 象 后 将 党 试 使 用 
kubectl 创 建 Deployment 和 Service 资 源 部 普 并 暴露 一 个 web 应用， 以 便 读 
者 快速 了 解 如 何在 Kubernetes 系 统 上 运行 应 用 程序 的 核心 任务 。 














2.1 Kubernetes 的 核心 对 象 


API Server 提 供 了 RESTful 风 格 的 编程 接口 ， 其 管理 的 资源 是 
Kubernetes API 中 的 端点 ， 用 于 存储 某 种 API 对 象 的 集合 ， 人 例如， 内置 
Pod 资 源 是 包含 了 所 有 Pod 对 象 的 集合 。 资 源 对 象 是 用 于 表现 集群 状态 的 
实体 ， 常 用 于 摘 述 应 于 哪个 节点 进行 容器 化 应 用 、 需 要 为 其 配置 什么 资 
源 以 及 应 用 程序 的 管理 策略 等 ， 例 如 ， 重 启 、 升 级 及 容错 机 制 。 男 外 ， 
一 个 对 象 也 是 一 种 “ 意 癌 记录 ”一 一 旦 创建 ，Kubernetes 束 需要 一 直 确 保 
对 象 始终 存在 。Pod、Deployment 和 Service 等 都 是 最 常用 的 核心 对 象 。 





2.1.1 Pod 资 源 对 象 


Pod 资 源 对 象 是 一 种 集合 了 一 到 多 个 应 用 容器 、 存 储 资源 、 专 用 IP 
及 支撑 容器 运行 的 其 他 选项 的 逻辑 组 件 ， 如 图 2-1 所 示 。 换 言 之 ，Pod 代 
表 独 Kubernetes 的 部 署 单 元 及 原子 运行 单元 ， 即 一 个 应 用 程序 的 单一 运 
行 实 例 ， 它 通常 由 共享 资源 昌 关 系 紧密 的 一 个 或 多 个 应 用 容 右 组 成 。 
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图 2-1 Pod 通常 由 一 到 多 个 共享 网 络 和 存储 资源 的 容器 组 合 而 成 


Kubernetes 的 网 络 模型 要 求 其 各 Pod 对 象 的 人 P 地 址 位 于 同一 网 络 平面 
内 (同一 JP 网 段 ，， 各 Pod 之 间 可 使 用 其 IP 地 址 直接 进行 通信 ， 无 论 它 
们 运行 于 集群 内 的 哪个 工作 节点 之 上 ， 这 些 Pod 对 象 都 像 是 运行 于 同一 
局 域 网 中 的 多 个 主机 。 


读者 可 以 将 每 个 Pod 对 象 想 象 成 一 个 逻辑 主机 ， 它 类 似 于 现实 世界 
中 的 物理 主机 或 VM (Virtual Machine) ， 运 行 于 同一 个 Pod 对 象 中 的 多 
个 进程 也 类 似 于 物理 机 或 VM 上 独立 运行 的 进程 。 不 过 ，Pod 对 象 中 的 各 
进程 均 运 行 于 彼此 隔离 的 容器 中 ， 并 于 各 容 右 间 共 享 两 种 关键 资源 ， 网 
络 和 存储 卷 。 


网络 Cnetworking) : 每 个 Pod 对 象 都 会 被 分 配 一 个 集群 内 专用 的 
IP 地 址 ， 也 称 为 Pod IP， 同 一 Pod 内 部 的 所 有 容 右 共享 Pod 对 象 的 Network 
和 UTS 名 称 空间 ， 其 中 包括 主机 名 、IP 地 址 和 端口 等 。 因 此 ， 这 些 容器 
间 的 通信 可 以 基于 本 地 回环 接口 lo 进行 ， 而 与 Pod 外 的 其 他 组 件 的 通信 























则 需要 使 用 Service 资 源 对 象 的 ClusterIP 及 其 相应 的 端口 完成 。 


:存储 卷 (volume) : 用 户 可 以 为 Pod 对 象 配置 一 组 “存储 卷 ?资源 ， 
这 些 资 源 可 以 共享 给 其 内 部 的 所 有 容器 使 用 ， 从 而 完成 容器 间 数 据 的 共 
享 。 存储 卷 还 可 以 确保 在 容器 终止 后 被 重启 ， 其 至 是 被 删除 后 也 能 确保 
数据 不 会 丢失 ， 从 而 保证 了 生命 周期 内 的 Pod 对 象 数 据 的 持久 化 存储 。 


一 个 Pod 对 象 代 表 某 个 应 用 程序 的 一 个 特定 实例 ， 如 果 需 要 扩展 应 
用 程序 ， 则 意味 着 为 此 应 用 程序 同时 创建 多 个 Pod 实 例 ， 每 个 实例 均 代 
表 应 用 程序 的 一 个 运行 的 “副本 ”(replica) 。 这 些 副 本 化 的 Pod 对 象 的 创 
建 和 管理 通常 由 另 一 组 称 之 为 “控制 器 ”(Controller) 的 对 象 实现 ， 例 
如 ，Deployment 控 制 器 对 象 。 


创建 Pod 时 ， 还 可 以 使 用 Pod Preset 对 象 为 Pod 注 入 特定 的 信息 ， 如 
ConfigMap、Secret、 存 储 卷 、 卷 挂 载 和 环境 变量 等 。 有 了 Pod Preset 对 
象 ，Pod 模 板 的 创建 者 就 无 须 为 每 个 模板 显 式 提供 所 有 信息 ， 因 此 ， 也 
惑 无 须 事先 了 解 需要 配置 的 每 个 应 用 的 细节 即 可 完成 模板 定义 。 这 些 内 
容 将 在 后 面 的 章节 中 了 予以 介绍 。 


基于 期 望 的 目标 状态 和 各 节点 的 资源 可 用 性 ，Master 会 将 Pod 对 象 
调度 至 某 选 定 的 工作 节点 运行 ， 工 作 节 点 于 指 同 的 镜像 仓库 〈image 
registry) 下 载 镜 像 ， 并 于 本 地 的 容器 运行 时 环境 中 启动 容器 。Master 会 
0 并 通过 API Server 共 享 给 集群 的 各 组 件 
及 客户 端 。 


























2.1.2 Controller 


Kubernetes 集 群 的 设计 中 ，Pod 是 有 生命 周期 的 对 象 。 用 户 通 过 手工 
创建 或 由 Controller 〈 控 制 器 ) 直接 创建 的 Pod 对 象 会 被 * 调 度 
器 ”(Scheduler) 调度 至 集群 中 的 某 工 作 节 点 运行 ， 待 到 容器 应 用 进程 
运行 结束 之 后 正常 终止 ， 随 后 束 会 被 删除 。 男 外 ， 市 点 资源 耗 尽 或 故障 
也 会 导致 Pod 对 象 被 回收 。 


但 Pod 对 象 本 身 并 不 具有 “和 目 您 ”功能 ， 知 是 因为 工作 节点 甚至 是 调 
度 器 目 身 导致 了 运行 失败 ， 那 么 它 将 会 被 删除 ， 同 样 ， 资 源 耗 尽 或 节点 
故障 导致 的 回收 操作 也 会 删除 相关 的 Pod 对 象 。 在 设计 上 ，Kubernetes 使 
用 “控制 器 ”实现 对 一 次 性 的 〈 用 后 即 弃 ) Pod 对 象 的 管理 操作 ， 例 如 ， 
要 确保 部 署 的 应 用 程序 的 Pod 副 本 数量 严格 反映 用 户 期 望 的 数目 ， 以 及 
基于 Pod 模 板 来 重建 Pod 对 象 等 ， 从 而 实现 Pod 对 象 的 扩 缩 容 、 滚 动 更 新 
和 目 愈 能 力 等 。 例 如 ， 某 节点 发 生 故 障 时 ， 相 关 的 控制 器 会 将 此 节点 上 
运行 的 Pod 对 象 重 新 调度 到 其 他 节点 进行 重建 。 


控制 器 本 身 也 是 一 种 资源 类 型 ， 它 有 着 多 种 实现 ， 其 中 与 工作 负载 
相关 的 实现 如 Replication Controller、Deployment、 StatefulSet、 
DaemonSet、DaemonSet 和 Jobs 等 ， 也 可 统称 它们 为 Pod 控 制 器 。 如 图 2-2 
中 的 Deployment 束 是 这 类 控制 器 的 代表 实现 ， 是 目前 最 常用 的 管理 无 状 
态 应 用 的 Pod 控 制 器 。 


Pod 控 制 占 的 定义 通常 由 期 望 的 副本 数量 、Pod 模 板 和 标签 选择 器 
(Label Selector) 组 成 。Pod 控 制 器 会 根据 标签 选择 器 对 Pod 对 象 的 标签 
进行 匹配 检查 ， 所 有 满足 选择 条 件 的 Pod 对 象 都 将 受 控 于 当前 控制 占 并 
计 入 其 副本 总 数 ， 并 确保 此 数目 能 够 精确 反映 期 望 的 副本 数 。 


需要 注意 的 是 ， 在 实际 的 应 用 场景 中 ， 在 接收 到 的 请 求 流量 负载 显 
车 低 于 或 接近 于 已 有 Pod 副 本 的 整体 承载 能 力 时 ， 用 户 需 要 手动 修改 Pod 
控制 器 中 的 期 望 副本 数量 以 实现 应 用 规模 的 扩容 或 缩 容 。 不 过 ， 知 集群 
中 部 署 了 HeapSter 或 Prometheus 一 类 的 资源 指标 监控 附件 时 ， 用 户 还 可 
以 使 用 “HorizontalPodAutoscaler”(HPA) 计算 出 合适 的 Pod 副 本 数量 ， 
并 上 自动 修改 Pod 控 制 占 中 期 望 的 副本 数 以 实现 应 用 规模 的 动态 伸缩 ， 提 
高 集群 资源 利用 率 ， 如 图 2-3 所 示 。 





























Kubernetes 集 群 中 的 每 个 节点 都 运行 着 cAdvisor 以 收集 容器 及 节点 
的 CPU、 内 存 及 磁盘 资源 的 利用 率 指标 数据 ， 这 些 统计 数据 由 Heapster 
聚合 后 可 通过 API Server 访 问 。HorizontalPodAutoscaler 基 于 这 些 统计 数 
据 监控 容 需 健康 状态 并 做 出 扩展 决策 。 
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图 2-2 Replication Controller 
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图 2-3 Horizontal Pod Autoscaler 


2.1.3 Service 





尽管 Pod 对 象 可 以 拥有 IP 地 址 ， 但 此 地 址 无 法 确保 在 Pod 对 象 重启 或 
被 重建 后 保持 不 变 ， 这 会 为 集群 中 的 Pod 必 用 间 依 赖 关 系 的 维护 融 来 厂 
烦 : 前 端 Pod 应 用 (依赖 方 ) 无 法 基于 固定 地 址 持续 跟踪 后 端 Pod 应 用 

(被 依赖 方 )。 于 是 ，Service 资 源 被 用 于 在 被 访问 的 Pod 对 象 中 添加 一 

个 有 着 固定 了 P 地 址 的 中 间 层 ， 客 户 端 向 此 地 址 发 起 访问 请 求 后 由 相关 的 
Service 资 源 调度 并 代理 至 后 端的 Pod 对 象 。 

换言之 ，Service 是 “微服 务 ” 的 一 种 实现 ， 事 实 上 它 是 一 种 抽象 : 通 
过 规则 定义 出 由 多 个 Pod 对 象 组 合 而 成 的 逻辑 集合 ， 并 附带 访问 这 组 Pod 
对 象 的 策略 。Service 对 象 挑 选 、 关 联 Pod 对 象 的 方式 同 Pod 控 制 器 一 样 ， 
都 是 要 基于 Label Selector 进 行 定义 ， 其 示意 图 如 图 2-4 所 示 。 
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图 2-4 ”Service 对 象 功能 示意 图 


Service IP 是 一 种 虚拟 卫 ， 也 称 为 Cluster IP， 它 专用 于 集群 内 通信 ， 
通常 使 用 专用 的 地 址 段 ， 如 “10.96.0.0/12” 网 络 ， 各 Service 对 象 的 IP 地 址 
在 此 范围 内 由 系统 动态 分 配 。 


集群 内 的 Pod 对 象 可 直接 请 求 此 类 的 Cluster IP， 例 如 ， 图 2-4 中 来 自 
pod client 的 访问 请 求 即 可 以 Service 的 Cluster IP 作 为 目标 地 址 ， 但 集群 网 
络 属于 私有 网 络 地 址 ， 它 们 仅 在 集群 内 部 可 达 。 将 集群 外 部 的 访问 流量 
引入 集群 内 部 的 常用 方法 是 通过 节点 网 络 进行 ， 实 现 方法 是 通过 工作 节 
点 的 卫 地 址 和 某 端 口 (NodePort) 接 入 请 求 并 将 其 代理 至 相应 的 Service 
对 象 的 Cluster IP 上 的 服务 端口 ， 而 后 由 Service 对 象 将 请 求 代 理 至 后 端的 
Pod 对 象 的 Pod 了 P 了 及 应 用 程序 监听 的 端口 。 因 此 ， 诸 如 图 2-4 中 的 External 
Clients 这 种 来 自 集 群 外 部 的 客户 端 无 法 直接 请 求 此 Service 提 供 的 服务 ， 
而 是 需要 事先 经 由 某 一 个 工作 节点 〈 如 NodeY) 的 IP 地 址 进行 ， 这 类 请 
人 目标 Pod 对 象 ， 因 此 在 通信 效率 上 必然 存在 负 
面 影 啊 。 


事实 上 ，NodePort 会 部 署 于 集群 中 的 每 一 个 节点 ， 这 束 意 味 着 ， 集 
群 外 部 的 客户 端 通过 任何 一 个 工作 节点 的 卫 地 址 来 访问 定义 好 的 
NodePort 都 可 以 到 达 相 应 的 Service 对 象 。 此 种 场景 中 ， 如 果 存 在 集群 外 
部 的 一 个 负载 均衡 器， 即 可 将 用 户 请 求 负 和 载 均 衡 至 集群 中 的 部 分 或 者 所 
有 节点 。 这 是 一 种 称 为 “LoadBalancer”* 类 型 的 Service， 它 通常 是 由 Cloud 
Provider 上 自动 创建 并 提供 的 软件 负载 均衡 器 ， 不 过 ， 也 可 以 是 由 管理 员 
手工 配置 的 诸如 F5Big-IP 一 类 的 硬件 设备 。 


简单 来 说 ，Service 主 要 有 三 种 滑 用 类 型 : 第 一 种 是 仅 用 于 集群 内 部 
通信 的 ClusterIP 类 型 ， 第 二 种 是 接 入 集群 外 部 请 求 的 NodePort 类 型 ， 它 
工作 于 每 个 节点 的 主机 了 P 之 上 ;， 第 三 种 是 LoadBalancer 类 型 ， 它 可 以 把 
外 部 请 求 负 载 均 衡 至 多 个 Node 的 主机 IP 的 NodePort 之 上 。 此 三 种 类 型 
中 ， 每 一 种 都 以 其 前 一 种 为 基础 才能 实现 ， 而 且 第 三 种 类 型 中 的 
LoadBalancer 需 要 协同 集群 外 部 的 组 件 才 能 实现 ， 并 且 此 外 部 组 件 并 不 
接受 Kubernetes 的 管理 。 


























2.1.4， 部署 应 用 程序 的 主体 过 程 


Docker 容 吉 技 术 使 得 部 署 应 用 程序 从 传统 的 安装 、 配 置 、 局 动 应 用 
程序 的 方式 转 为 于 容器 引擎 上 基于 镜像 创建 和 运行 容器 ， 而 Kubernetes 
又 使 得 创建 和 运行 容器 的 操作 不 必 再 关注 其 位 置 ， 并 在 一 定 程度 上 赋予 
了 它 动态 扩 缩 容 及 目 愈 的 能 力 ， 从 而 让 用 户 从 主机 、 系 统 及 应 用 程序 的 
维护 工作 中 解脱 出 来 。 


用 到 某 应 用 程序 时 ， 用 户 只 需要 向 API Server 请 求 创建 一 个 Pod 控 制 
器 ， 由 控制 器 根据 镜像 等 信息 向 API Server 请 求 创建 出 一 定数 量 的 Pod 对 
象 ， 并 由 Master 之 上 的 调度 器 指派 至 选 定 的 工作 节点 以 运行 容器 化 应 
用 。 此 外 ， 用 户 一 般 还 需要 创建 一 个 具体 的 Service 对 象 以 便 为 这 些 Pod 
对 象 建立 起 一 个 固定 的 访问 入 口 ， 从 而 使 得 其 客户 端 能 够 通过 其 服务 名 
称 或 ClusterIP 进 行 访 问 ， 如 图 2-5 所 示 。 
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图 2-5 ”应 用 程序 简单 的 部 车 示例 


API Server 的 常用 客户 端 程序 是 Kubernetes 系 统 自 带 的 命令 行 工 具 
kubectl， 它 通过 一 众 子 命令 用 于 实现 集群 及 相关 资源 对 象 的 管理 操作 ， 
并 文 持 直接 命令 式 、 命 令 式 配置 清单 及 声明 式 配 置 清单 等 三 种 操作 方 
式 ， 特 性 丰富 且 功 能 强大 。 而 需 作 为 集群 附件 额外 部 晋 的 Dashboard 则 
提供 了 基于 Web 界 面 的 图 形 客 户 端 ， 它 是 一 个 通用 目的 管理 工具 ， 与 
Kubernetes 紧 密集 成 ， 文 持 多 级 别 用 户 授权 ， 能 在 一 定 程度 上 蔡 代 
kubectl 的 大 多 数 操作 。 


本 章 后 面 的 篇 幅 将 介绍 在 部 署 完 成 的 Kubernetes 集 群 环 境 中 如 何 快 
速 部 署 如 图 2-5 所 示 的 示例 应 用 程序 ， 并 简单 说 明 如 何 完 成 对 容器 化 应 
用 的 访问 ， 以 及 如 何 进 行 应 用 规模 的 动态 伸缩 ， 并 借 此 让 读者 了 解 
kubectl 命 令 的 基本 功能 和 用 法 。 





2.2 部署 Kubernetes 集 和 群 


Kubernetes 系 统 可 运行 于 多 种 平台 之 上 ， 包 括 虚 拟 机 、 裸 服务 器 或 
PC 等 ， 例 如 本 地 主机 或 托管 的 云端 虚拟 机 。 知 仅 用 于 快速 了 解 或 开发 
的 目的 ， 那 么 读者 可 直接 于 单个 主机 之 上 部 署 “ 伪 ”分布 式 的 Kubernetes 
集群 ， 将 集群 的 所 有 组 件 均 部 署 运行 于 单 台 主机 上 ， 著 名 的 minukube 项 
目 可 帮助 用 户 快 速 构建 此 类 环境 。 如 果 要 学 习 使 用 Kubernetes 集 群 的 完 
整 功能 ， 则 应 该 构建 真正 的 分 布 式 集群 环境 ， 将 Master 和 Node 等 部 署 于 

台 主 机 之 上 ， 主 机 的 具体 数量 要 按 实 际 需求 而 定 。 另 外 ， 集 群 部 署 的 
方式 也 有 多 种 选择 ， 简 单 的 可 以 基于 kubeadm 一 类 的 部 署 工 具 运 行 几 条 
命令 即 可 实现 ， 而 复杂 的 则 可 以 是 从 零 开 始 手动 构建 集群 环境 。 























2.2.1 kubeadm 部 署 工 具 


kubeadm 是 Kubernetes 项 目 自 带 的 集群 构建 工具 ， 它 负责 执行 构建 
一 个 最 小 化 的 可 用 集群 以 及 将 其 启动 等 的 必要 基本 步骤 ， 和 人 简单 来 讲 ， 
kubeadm 是 Kubernetes 集 群 全 生命 周期 的 管理 工具 ， 可 用 于 实现 集群 的 
部 署 、 升 级 /降级 及 拆除 ， 如 图 2-6 所 示 。 不 过 ， 在 部 署 操 作 中 ， 
kubeadm 仅 关心 如 何 初始 化 并 局 动 集 群 ， 余 下 的 其 他 操作 ， 例 如 安装 
Kubernetes Dashboard、 监 控 系 统 、 日 志 系 统 等 必要 的 附加 组 件 则 不 在 其 
考虑 范围 之 内 ， 和 需要 管理 员 按 需 目 行 部 署 。 
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图 2-6 ”kubeadm 功 能 示意 图 


kubeadm 集 成 了 kubeadm init 和 kubeadm join 等 工具 程序 ， 其 中 
kubeadm init 用 于 集群 的 快速 初始 化 ， 其 核心 功能 是 部 署 Master 节 点 的 各 
个 组 件 ， 而 kubeadm join 则 用 于 将 节点 快速 加 入 到 指定 集群 中 ， 它 们 是 
创建 Kubernetes 集 群 最 佳 实践 的 “快速 路 径 >”。 另 外 ，kubeadm token 可 于 
集群 构建 后 管理 用 于 加 入 集群 时 使 用 的 认证 令 牌 〈token) ， 而 kubeadm 
reset 命 令 的 功能 则 是 删 除 集群 构建 过 程 中 生成 的 文件 以 重 置 回 初 始 状 


4 Oo 





kubeadm 还 支持 管理 初始 引导 认证 令 牌 (Bootstrap Token) ， 完 成 
待 加 入 的 新 节点 首次 联系 API Server 时 的 身份 认证 (基于 共享 密 钥 ) 。 
另外 ， 它 们 还 文 持 管理 集群 版 本 的 升级 和 降级 操作 。Kubernetes 1.8 版 本 


之 前 ，kubeadm 一 直 处 于 beta 级 别 ， 并 警告 不 能 用 于 生产 环境 。 不 过 ， 

目 1.9 版 本 开始 ， 其 虽 仍 处 于 beta 版 本 ， 但 已 经 不 再 输出 警告 信息 ， 而 随 
着 1.11 版 本 发 布 的 kubeadm 叉 得 到 了 进一步 的 增强 ， 它 支持 动态 配置 
kubelet， 通 过 增强 的 CRI 和 集成 支持 动态 探测 以 判定 所 用 的 容器 引擎 ， 并 
引入 了 几 个 新 的 命令 行 工 具 ， 包 括 kubeadm config print-default、 
kubeadm config migrate、kubeadm config images pull 和 kubeadm upgrade 
node config 等 。 总 体 来 说 ， 使 用 kubeadm 部 署 Kubernetes 集 群 具 有 如 下 几 
个 方面 的 优势 。 


-简单 易 用 : kubeadm 可 完成 集群 的 部 普 、 升 级 和 拆除 操作 ， 并 且 对 
新 手 用 户 非常 友好 。 


.适用 领域 广泛 : 支持 将 集群 部 署 于 裸 机 、VMware、AWS、 
Azure、GCE 及 更 多 环境 的 主机 上 ， 且 部 署 过 程 基本 一 致 。 


是 有 弹性 : 1.11 厂 中 的 kubeadm 文 持 阶 段 式 部 着 ， 管 理 员 可 分 为 多 


个 独立 步骤 完成 部 著 操 作 。 


.生产 环境 可 用 : kubeadm 遵 循 以 最 佳 实践 的 方式 部 署 Kubernetes 集 
群 ， 它 强制 启用 RBAC， 设 定 Master 的 各 组 件 间 以 及 API Server 与 kublet 
之 间 进 行 认 证 及 安全 通信 ， 并 锁定 了 kubelet API 等 。 


由 此 可 见 ，kubeadm 并 非 一 键 安 装 类 的 解 诀 方案， 相反 ， 它 有 着 更 
宏大 的 目标 ， 旨 在 成 为 一 个 更 大 解决 方案 的 一 部 分 ， 试 图 为 集群 创建 和 
运营 构建 一 个 声明 式 的 API 驱 动 模型 ， 它 将 集群 本 里 视 为 不 可 变 组 件 ， 
而 升级 操作 等 同 于 全 新 部 署 或 就 地 更 新 。 目 前 ， 使 用 kubeadm 部 署 集 群 
已 经 成 为 越 来 越 多 的 Kubernetes 工 程 师 的 选择 。 




















2.2.2 ”集群 运行 模式 


Kubernetes 集 群 文 持 三 种 运行 模式 : 





一 是 “独立 组 件 ?模式 ， 系 统 各 


组 件 直 接 以 守护 进程 的 方式 运行 于 斑点 之 上 ， 各 组 件 之 间 相 互 协 作 构 成 


集群 ， 如 图 2-7b 所 示 ; 第 二 种 是 “静态 Pod 模 式 ”， 





除 kubelet 和 Docker 之 外 


的 其 他 组 件 〈 如 etcd、kube-apiserver、kube-controller-manager 和 kube- 


scheduler 等 


示 ; 第 三 种 是 Kubernetes 的 “ 自 托管 





) 都 是 以 静态 Pod 对 象 运行 于 Master 主 机 之 上 的 ， 如 图 2-7a 所 
管 ”(self-hosted) 模式 ， 它 类 似 于 第 二 


种 方式 ， 将 除了 kubelet 和 Docker 之 外 的 其 他 组 件 运 行为 集群 之 上 的 Pod 


对 象 ， 但 不 同 的 是 ， 


这 些 Pod 对 象 托 


DaemonsSet 类 型 的 控制 项 ， 而 非 静态 的 Pod 对 象 。 


Kubernetes cluster 


master 


proxy 
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管 运行 在 集群 自身 之 上 受 控 于 


Kubernetes cluster 


Pod 


node 


proxy 


kubelet docker 


b) 


图 2-7 ”Kubernetes 集 群 的 运行 模式 (图 2-7a 为 静态 Pod 模 式 ) 
使 用 kubeadm 部 署 的 Kubernetes 集 群 可 运行 为 第 二 种 或 第 三 种 模 


式 ， 


默认 为 静态 Pod 对 象 模式 ， 


令 使 用 “--features-gates=selfHosting” 选 项 即 可 。 第 
于 系统 之 上 的 独立 守护 进程 中 ， 其 间 需 要 用 到 的 证 书 


需要 将 各 组 件 运 行 
及 Token 等 认证 信息 也 都 需要 手动 生成 ， 过 程 烦 珊 且 极 易 出 错 ; 


需要 使 用 自 托管 模式 时 ，kubeadm init 命 


一 种 模式 集群 的 构建 
大 有 必 


要 用 到 ， 则 建议 使 用 GitHub 上 合用 的 项 目 辅助 进行 ， 例 如 ， 通 过 ansible 
Playbook 进 行 自 动 部 署 等 。 


2.2.3 ”准备 用 于 实践 操作 的 集群 环境 


本 书后 面 的 篇 幅 中 用 到 的 测试 集群 如 图 2-8 所 示 ， 该 集群 由 一 个 
Master 主 机 和 三 个 Node 主 机 组 成 ， 它 基于 kubeadm 部 署 ， 除 了 kubelet 和 
Docker 之 外 其 他 的 集群 组 件 都 运行 于 Pod 对 象 中 。 多 数 情况 下 ， 两 个 或 
以 上 的 独立 运行 的 Node 主 机 即 可 测试 分 布 式 集群 的 核心 功能 ， 因 此 其 数 
量 可 按 需 定义 ， 但 两 个 主机 是 模拟 分 布 式 环境 的 最 低 需 求 。 生 产 实践 
中 ， 应 该 至 少 部 署 三 个 协同 工作 的 Master 节 点 以 确保 控制 平面 的 服务 可 
用 性 ， 不 过 ， 在 测试 环境 中 仪 部 署 一 个 Master 闻 点 也 是 常见 的 选择 。 
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竹 点 网 络 : 172.16.0.0/16 





Pod 网 络 : 10.244.0.0/16 


图 2-8 ”Kubernetes 集 群 部 署 日 标示 意图 


PF HD 


各 Node 上 采用 的 容器 运行 时 环境 为 docker， 后 续 的 众多 容器 的 运行 
任务 都 将 依赖 于 Docker Registry 服 务 ， 包 括 DockerHub、GCR (Google 
Container Registry) 和 Quay 等 ， 甚 至 是 私有 的 Registry 服 务 ， 本 书 假设 读 
者 对 Docker 容 器 技术 有 熟练 的 使 用 基础 。 另 外 ， 本 部 署 示 例 中 使 用 的 用 
于 为 Pod 对 象 提 供 网 络 功能 的 插件 是 flannel， 其 同样 以 Pod 对 象 的 形式 托 
管 运行 于 Kubernetes 系 统 之 上 。 


具体 的 部 署 过 程 以 及 本 书 用 到 的 集群 环境 请 参考 附录 A， 本 章 后 续 
的 操作 都 将 依赖 于 根据 其 步骤 部 署 完成 的 集群 环境 ， 读 者 需要 根据 其 内 
容 成 功 搭建 出 Kubernetes 测 试 集群 后 才能 进行 后 面 章节 的 学 习 。 











2.2.4 获取 集群 环境 相关 的 信息 


Kubernetes 系 统 目前 仍 处 于 快速 迭代 阶段 ， 版 本 演进 频繁 ， 读 者 所 
部 署 的 版 本 与 本 书 中 使 用 的 版 本 或 将 有 所 不 同 ， 其 功能 特性 也 将 存在 一 
定 程 度 的 变动 。 因 此 ， 事 先 查 看 系统 版 本 ， 以 及 对 比 了 解 不 同 版 本 间 的 
功能 特性 变动 也 将 是 不 可 或 缺 的 步 又。 当然 ， 用 户 也 可 选择 安装 与 本 书 
人 的 系统 版 本 。 下 面 的 命令 显示 的 是 当前 使 用 的 客户 端 及 服务 端 程序 
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[root@master ~]# kubect1 version --Short=true 
Client Version: v1.12.1 
Server Version: v1.12.1 





@ 提示 。 Kubermetes 系 统 版 本 变动 时 的 ChangeLog 可 参考 
github.com 站 点 上 相关 版 本 中 的 介绍 。 


Kubernetes 集 群 以 及 部 署 的 附件 CoreDNS 等 提供 了 多 种 不 同 的 服 
务 ， 客 户 端 访 问 这 些 服 务 时 需要 事先 了 解 其 访问 接口 ， 管 理 员 可 使 
用 “kubectl cluster-info” 命 令 获 取 相 关 的 信息 。 





[root@master ~]# kubect1 cluster-info 

Kubernetes master is running at https://172.16.0.70:6443 

CoreDNS is running at https://172.16.0.70:6443/api/vi/namespaces/kube-system/ 
services/kube-dns:dns/proxy 





一 个 功能 完整 的 Kubernetes 集 群 应 当 具 备 的 附加 组 件 还 包括 
Dashboard、Ingress Controller 和 Heapster (或 Prometheus) 和 等， 后续 章节 
中 的 某 些 概念 将 会 依赖 到 这 些 组 件 ， 读 者 可 选择 在 将 要 用 到 时 再 进行 部 
署 。 


2.3 ”kubectl 使 用 基础 与 示例 


Kubernetes API 是 管理 其 各 种 资源 对 象 的 唯一 入 口 ， 它 提供 了 一 个 
RESTful 风 格 的 CRUD (Create、Read、Update 和 Delete〉 接 口 用 于 查询 
和 修改 集群 状态 ， 并 将 结果 存储 于 集群 状态 存储 系统 etcd 中 。 事 实 上 ， 
API server 也 是 用 于 更 新 etcd 中 资源 对 象 状态 的 唯一 途径 ，Kubernetes 的 
其 他 所 有 组 件 和 客户 端 都 要 通过 它 来 完成 查询 或 修改 操作 ， 如 图 2-9 所 
示 。 从 这 个 角度 来 讲 ， 它 们 都 算得 上 是 API server 的 客户 端 。 








' master 


| kube-controller-manager ] | kube-scheduler | 
kubectl + 一 一 一 一 一 kube-apiserver < 一 etcd | 























[reeked 
四 node docker 


图 2-9 API Server 及 其 部 分 客户 端 














任何 RESTfu 风 格 API 中 的 核心 概念 都 是 “资源 ”(resource) ， 它 是 
具有 类 型 、 关 联 数 据 、 同 其 他 资源 的 关系 以 及 可 对 其 执行 的 一 组 操作 方 
法 的 对 象 ， 它 与 对 象 式 编程 语言 中 的 对 象 实例 类 似 ， 两 者 之 间 的 重要 区 
别 在 于 RESTful API 仅 为 资源 定义 了 少量 的 标准 方法 〈 对 应 于 标准 HITP 
的 GET、POST、PUT 和 DELETE 方 法 ) ， 而 编程 语言 中 的 对 象 实例 通常 
有 很 多 方法 。 另 外 ， 资 源 可 以 根据 其 特性 分 组 ， 每 个 组 是 同一 类 型 资源 
的 集合 ， 它 仅 包 含 一 种 类 型 的 资源 ， 并 且 各 资源 间 不 存在 顺序 的 概念 ， 
集合 本 身 也 是 资源 。 对 应 于 Kubernetes 中 ，Pod、Deployment 和 Service 等 








都 是 所 谓 的 资源 类 型 ， 它 们 由 相应 类 型 的 对 象 集合 而 成 。 


API Server 通 过 认证 (Authentication ) 、 授 权 (Authorization ) 和 人 准 
入 控制 (Admission Control) 等 来 管理 对 资源 的 访问 请 求 ， 因 此 ， 来 目 
于 任何 客户 端 ( 如 kubectl、kubelet、kube-proxy 等 〉 的 访问 请 求 都 必须 
事先 完成 认证 之 后 方 可 进行 后 面 的 其 他 操作 。API Server 文 持 多 种 认证 
方式 ， 客 户 问 可 以 使 用 命令 行 选项 或 专用 的 配置 文件 ( 称 大 
人 提供 认证 信息 。 相 关 的 内 容 将 在 后 面 的 章节 中 给 予 详细 说 
明 。 


kubectl 的 核心 功能 在 于 通过 API Server 操 作 Kubemetes 的 各 种 资源 对 
象 ， 它 文 持 三 种 操作 方式 ， 其 中 直接 命令 式 (Imperative commands) 的 
使 用 最 为 简便 ， 是 了 解 Kubernetes 集 群 管理 的 一 种 有 效 途 径 。 


kubectl 命 令 和 常用 操作 示例 


为 了 便于 读者 快速 适应 kubectl 的 命令 操作 ， 这 里 给 出 几 个 使 用 示例 
用 于 说 明 其 基本 使 用 方法 。 


1. 创 建 资源 对 象 
直接 通过 kubectl 命 令 及 相关 的 选项 创建 资源 对 象 的 方式 即 为 直接 命 


令 式 操作 ， 例 如 下 面 的 命令 分 别 创建 了 名 为 nginx-deploy 的 Deployment 
控制 器 资源 对 象 ， 以 及 名 为 nginx-svc 的 Service 资 源 对 象 : 





$ kubectl run nginx-deploy --image=nginx:1.12 --replicas=2 
$ kubect1 expose deployment/nginx --name=nginx-svc --port=80 





用 户 也 可 以 根据 资源 清单 创建 资源 对 象 ， 即 命令 式 对 象 配 置 文 件 ， 
例如 ， 假 设 存在 定义 了 Deployment 对 象 的 nginx-deploy.yaml 文 件 ， 和 害 
义 了 Service 对 象 的 nginx-svc.yaml 文 件 ， 使 用 kubectl create 命 令 即 可 进行 
基于 命令 式 对 象 配置 文件 的 创建 操作 : 





$ kubect1l create -f nginx-deploy.yaml -f nginx-svc.yaml 





甚至 还 可 以 将 创建 交 由 kubectl 上 自行 确定 ， 用 户 只 需要 声明 期 望 的 状 





态 ， 这 种 方式 称 为 声明 式 对 象 配 置 。 例如 ， 假设 存在 定义 了 Deployment 
对 象 的 nginx-deploy. yaml 文 件 ， 以 及 定义 了 Service 对 象 的 nginx-svc.yaml 
文件 ， 那 么 使 用 kubectl apply 命 令 即 可 实现 声明 式 配 置 : 





$ kubect1 apply -f nginx-deploy.yaml -f nginx-svc.yaml 








本 章 后 面 的 章节 主要 使 用 第 一 种 资源 管理 方式 ， 第 二 种 和 第 三 种 方 
式 将 在 后 面 的 章节 中 展开 讲述 。 


2. 查 看 资源 对 象 


运行 着 实际 负载 的 Kubernetes 系 统 上 通常 会 存在 多 种 资源 对 象 ， 用 

可 分 类 列 出 感 兴趣 的 资源 对 象 及 其 相关 的 状态 信息 ，“kubectl get” 正 
是 用 于 完成 此 关 功 E 的 命令 。 例 如 ， 列 出 系统 上 所 有 的 Namespace 资 源 
对 象 ， 命 令 如 下 : 








$kubectl] get namespaces 





用 户 也 可 一 次 查看 多 个 资源 类 别 下 的 资源 对 象 ， 例 如 ， 列 出 默认 名 
称 空间 内 的 所 有 Pod 和 Service 对 象 并 输出 额外 信息 ， 可 以 使 用 如 下 形 
式 的 kubect get 命 令 : 





$kubectl1 get pods, services-o wide 





Kubernetes 系 统 的 大 部 分 资源 都 隶属 于 某 个 Namespace 对 象 ， 缺 省 的 
名 称 空 间 为 default， 知 需要 获取 指 定 Namespace 对 角 中 的 资源 对 象 的 信 
晨 ， 则 需 i 要 使 用 日 -n 或 --namespace 指 明 其 名 称 。 例 如 ， 列 出 kube- 
namespace 名 称 空间 中 拥有 k8s-app 标 签名 称 称 的 所 有 Pod 对 象 : 








$kubect1 get pods-1] k8s-app-n kube-system 





3. 打 印 资 源 对 象 的 详细 信息 


每 个 资源 对 象 都 包含 着 用 户 期 望 的 状态 〈Spec) 和 现 有 的 实际 状态 
(Status ) 两 种 状态 信息 ，“kubectl get-ofyamlljosn}” 或 “kubectl 


describe” 命 令 都 能 够 打印 出 指定 资源 对 象 的 详细 描述 信息 。 例 如 ， 碍 看 
kube-system 名 称 空间 中 拥有 标签 component=kube-apiserver 的 Pod 对 象 的 
资源 配置 清单 〈 期 望 的 状态 ) 及 当前 的 状态 信息 ， 并 输出 为 yaml 格 式 ， 


命令 如 下 : 





$kubectl1 get pods- component=kube-apiserver-o yaml-n kube-system 








而 “kubectl describe” 命 令 还 能 显示 与 当前 对 象 相关 的 其 他 资源 对 
象 ， 如 Event 或 Controller 等 。 例 如 ， 查 看 kube-system 名 称 空间 中 拥有 标 
签 component=kube-apiserver 的 Pod 对 象 的 详细 描述 信息 ， 可 以 使 用 下 面 





$kubectl1 describe pods- component=kube-apiserver-n kube-system 





这 两 个 命令 都 支持 以 “TYPE NAME” 或 “TYPE/NAME” 的 格式 指定 具 
体 的 资源 对 象 ， 如 “pods kube-apiserver-master.ilinux.io” 或 “pods/kube- 
apiserver-master.ilinux.io”， 以 了 解 特定 资源 对 象 的 详细 属性 信息 及 状态 
兰 自 
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4. 打 印 容 器 中 的 日 志 信 息 


通常 一 个 容器 中 仪 会 运行 一 个 进程 (及 其 子 进程 》， 此 进程 作为 

PID 为 1 的 进程 接收 并 处 理 管理 信息 ， 同 时 将 日 志 直 接 输出 至 终端 中 ， 而 
无 须 再 像 传 统 的 多 进程 系统 环境 那样 将 日 志保 存 于 文件 中 ， 因 此 容器 日 
志 信 息 的 获取 一 般 要 到 其 控制 上 进行 。“kubectl logs” 命 令 可 打印 Pod 对 
象 内 指定 容器 的 日 志 信 息 ， 命 令 格 式 为 “kubect] logs[-f][-p] 

(PODITYPE/NAME) [-c CONTAINER][options]”， 若 Pod 对 象 内 仅 有 一 
个 容器 ， 则 -c 选 项 及 容器 名 为 可 选 。 例 如 ， 查 看 名 称 空间 kube-system 中 
仅 有 一 个 容器 的 Pod 对 象 kube-apiserver-master.ilinux.io 的 日 志 : 











$kubectl1 logs kube-apiserver-master.ilinux.io-n kube-system 





为 上 面 的 命令 添加 “-f»” 选 项， 还 能 用 于 持续 监控 指定 容器 中 的 日 志 
输出 ， 其 行为 类 似 于 使 用 了 -f 选 项 的 tail 命 令 。 


5. 在 容器 中 执行 命令 


容器 的 隔离 属性 使 得 对 其 内 部 信息 的 获取 变 得 不 再 直观 ， 这 一 点 在 
用 户 需要 了 解 容 器 内 进程 的 运行 特性 、 文 件 系统 上 的 文件 及 路 径 布局 等 
信息 时 ， 需 要 穿 透 其 隔离 边界 进行 。“kubectl exec”* 命 令 便 是 用 于 在 指定 
的 容器 内 运行 其 他 应 用 程序 的 命令 ， 例 如 ， 在 kube-system 名 称 空间 中 的 
Pod 对 象 kube-apiserver-master.ilinux.io 上 的 唯一 容器 中 运行 ps 命令 : 





$kubectl1 exec kube-apiserver-master.ilinux.io-n kube-system--ps 





注意 ， 硝 Pod 对 象 中 存在 多 个 容器 ， 则 需要 以 -c 选 项 指定 容 右 后 再 
运行 。 


6. 删 除 资源 对 象 


使 命 已 经 完成 或 存在 错误 的 资源 对 象 可 使 用 “kubectl delete” 命 令 子 
以 删除 ， 不 过 ， 对 于 受 控 于 控制 器 的 对 象 来 说 ， 删 除 之 后 其 控制 器 可 能 
会 重建 出 类 似 的 对 象 ， 例 如 ，Deployment 控 制 器 下 的 Pod 对 象 在 被 删除 
时 就 会 和 重建 例如 ， 删 除 默 认 名 称 空间 中 名 为 nginx-svc 的 Service 资 源 
对 象 : 





$kubect1 delete services nginx-svc 





下 面 的 命令 可 用 于 删除 kube-system 名 称 空间 中 拥有 标签 “k8s- 
app=kube-proxy” 的 所 有 Pod 对 象 : 





$kubect]1 delete pods-1 app=monitor-n kube-system 





在 要 删除 指定 名 称 空 间 中 的 所 有 的 某 类 对 象 ， 可 以 使 用 “kubectl 
delete TYPE--all-n NS 命令， 例如 ， 删 除 kube-public 名 称 空间 中 的 所 有 
Pod 对 象 : 





$kubect1 delete pods--all-n kube-public 





另外 ， 有 些 资源 类 型 《如 Pod) ， 文 持 优 雅 删除 的 机 制 ， 它 们 有 大 


默认 的 删除 宽 限 期 ， 不 过 ， 用 户 可 以 在 命令 中 使 用 --grace-period 选 项 或 - 
-n0w 选 项 来 覆盖 默认 的 宽 限 期 。 


2.4 ”命令 式 容 右 应 用 编排 


本 节 将 使 用 示例 镜像 “ikubemetes/myapp: V1” 来 演示 容器 应 用 编排 
的 基础 操作 : 应 用 部 署 、 访 问 、 查 看 、 服 务 暴 露 和 扩 缩 容 等 。 一 般 说 
来 ，Kubernetes 之 上 应 用 程序 的 基础 管理 操作 由 如 下 几 个 部 分 组 成 。 


1) 通过 合用 的 Controller 类 的 资源 〈 如 Deployment 或 
ReplicationController) 创建 并 管控 Pod 对 象 以 运行 特定 的 应 用 程序 ， 如 
Nginx 或 tomcat 等 。 无 状态 〈stateless) 应 用 的 部 署 和 控制 通常 使 用 
Deployment 控 制 器 进行 ， 而 有 状态 应 用 则 需要 使 用 StatefulSet 控 制 器 


2) 为 Pod 对 象 创建 Service 对 象 ， 以 便 同 客户 端 提供 固定 的 访问 路 
径 ， 并 借助 于 CoreDNS 进 行 服务 发 现 。 


人 3) 随时 按 需 获取 各 资源 对 象 的 简要 或 详细 信息 ， 以 了 解 其 运行 状 


4) 如 有 需要 ， 则 手动 对 文 持 扩 缩 容 的 Controller 组 件 进行 扩容 或 缩 
容 ; 或 者 ， 为 支持 HPA 的 Controller 组 件 〈( 如 Deployment 或 
ReplicationController) 创建 HPA 资 源 对 象 以 实现 Pod 副 本 数目 的 自动 伸 
缩 。 


5) 滚动 更 新 : 当 应 用 程序 的 镜像 出 现 新 版 本 时 ， 对 其 执行 更 新 操 
作 ; 0 ， 为 Pod 对 象 中 的 容器 更 新 其 镜像 版 本 ; 并 可 根据 需要 执行 
回 深 操作 。 


本 节 中 的 操作 示例 仅 演 示 了 前 三 个 部 分 的 功能 ， 即 应 用 的 部 车 、 服 
务 暴 露 及 相关 信息 的 查看。 应 用 的 扩 缩 容 、 升 级 及 回 滚 等 操作 会 在 后 面 
的 章节 中 进行 详细 介绍 











@ 提示 。 以 下 操作 命令 在 任何 部 团 了 kubectl 并 能 正常 访问 到 
Kubernetes 集 群 的 主机 上 均 可 执行 ， 包 括 集群 外 的 主机 。 复 制 master 主 
机 上 的 /etc/kubernetes/admin.conf 人 至 相关 用 户主 目录 下 的 .kube/config 文 件 
即 可 正常 执行 ， 具 体 方法 请 参考 kubeadm init 命 令 结果 中 的 提示 。 








2.4.1 部 普 应 用 (Pod) 


在 Kubernetes 集 群 上 自主 运行 的 Pod 对 象 在 非 计 划 内 终止 后 ， 其 生命 
周期 即 告 结 束 ， 用 户 需 要 再 次 手动 创建 类 似 的 Pod 对 象 才 能 确保 其 容器 
中 的 应 用 依然 可 得 。 对 于 Pod 数 量 众多 的 场景 ， 尤 其 是 对 微服 务 业 务 来 
说 ， 用 户 必 将 疲 于 应 付 此 类 需求 。Kubernetes 的 工作 负载 (workload ) 
类 型 的 控制 器 能 够 自动 确保 由 其 管控 的 Pod 对 象 按 用 户 期 望 的 方式 运 
行 ， 因 此 ，Pod 的 创建 和 管理 大 多 都 会 通过 这 种 类 型 的 控制 右 来 进行 ， 
包括 Deployment、ReplicaSet、ReplicationController 等 。 


1. 创 建 Deployment 控 制 器 对 象 


“kubectl run”* 命 令 可 于 命令 行 直接 创建 Deployment 控 制 器 ， 并 以 -- 
image 选 项 指定 的 镜像 运行 Pod 中 的 容器 ，--dry-run 选 项 可 用 于 命令 的 测 
试 运行 ， 但 并 未 真正 执行 资源 对 象 的 创建 过 程 。 例 如 ， 下 面 的 命令 要 创 
建 一 个 名 为 myapp 的 Deployment 控 制 器 对 象 ， 它 使 用 镜像 
ikubernetes/myapp: v1 创 建 Pod 对 象 ， 但 仅 在 测试 运行 后 即 退出 : 








~]$ kubectl run myapp --image=ikubernetes/myapp:v1 --port=80 --replicas=1 
--dry-run 

NAME AGE 

myapp <unknown> 





镜像 ikubernetes/myapp: v1 中 定义 的 容 喜 主 进程 为 默认 监听 于 80 端 
口 的 Web 服 务 程序 Nginx， 因 此 ， 如 下 命令 使 用 “--port=80” 来 指明 容器 要 
骏 露 的 端口 。 而 “--replicas=12? 选 项 则 指定 了 目标 控制 器 对 象 要 自动 创建 
的 Pod 对 象 的 副本 数量 。 确 认 测 试 命令 无 误 后 ， 可 移 除 “--dry-run? 选 项 后 
再 次 执行 命令 以 完成 资源 对 象 的 创建 : 





~]$ kubect1l run myapp --image=ikubernetes/myapp:v1 --port=80 --replicas=1 
deployment.apps/myapp created 





创建 完成 后 ， 其 运行 效果 示意 图 如 图 2-10 所 示 ， 它 在 default 名 称 空 
间 中 创建 了 一 个 名 为 myapp 的 Deployment 控 制 器 对 象 ， 并 由 它 基 于 指定 
的 镜像 文件 创建 了 一 个 Pod 对 象 。 


kubectl 


Kubernetes 
Cluster 





default namespace 


Selector 





图 2-10 ”Deployment 对 象 myapp 及 其 创建 的 Pod 对 象 


kubectl run 命 令 其 他 第 用 的 选项 还 有 如 下 几 个 ， 它 们 支持 用 户 在 创 
建 资源 对 象 时 实现 更 多 的 控制 ， 具 体 如 下 。 


-1|，--labels: 为 Pod 对 象 设 定 自 定义 标签 。 


'--Tecord: 是 否 将 当前 的 对 象 创建 命令 保存 至 对 象 的 Annotation 中 ， 
布尔 型 数据 ， 其 值 可 为 true 或 false。 


--save-config: 是 人 否 将 当前 对 象 的 配置 信息 保存 至 Annotation 中 ， 布 
尔 型 数据 ， 其 值 可 为 true 或 false。 


.--restart=Never: 创建 不 受 控制 器 管控 的 自主 式 Pod 对 象 。 
其 他 可 用 选项 及 使 用 方式 可 通过 “kubectl run--help” 命 令 获 取 。 资 源 


对 象 创建 完成 后 ， 通 常 需要 了 解 其 当前 状态 是 否 正 常 ， 以 及 是 否 能 够 易 
合 于 用 户 期 望 的 目标 状态 ， 相 关 的 操作 一 般 使 用 kubect] get、kubectl 


describe 等 命令 进行 。 
2. 打 印 资源 对 象 的 相关 信息 


kubectl get 命 令 可 用 于 获取 各 种 资源 对 象 的 相关 信息 ， 它 既 能 够 显 
示 对 象 类 型 特有 格式 的 简要 信息 ， 也 能 够 指定 出 格式 为 YAML 或 JSON 
的 详细 信息 ， 或 者 使 用 Go 模板 目 定 义 要 显示 的 属性 及 信息 等 。 例 如 ， 
相关 运行 状态 的 命令 及 其 输出 


~]$ kubect1l get deployments 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
myapp 1 1 1 1 





上 面 命 令 的 执行 结果 中 ， 各 字段 的 说 明 具 体 如 下 。 
1) NAME: 资源 对 象 的 名 称 。 
) DESIRED: 用 户 期 望 由 当前 控制 器 管理 的 Pod 对 象 副本 的 精确 





米 人 _ 瑟 


里 . 
3) CURRENT: 当前 控制 器 已 有 的 Pod 对 象 的 副本 数量 。 


4) UP-TO-DATE: 更 新 到 最 新 版 本 定义 的 Pod 对 象 的 副本 数量 ， 在 
它 表 示 已 经 完成 版 本 更 新 的 Pod 对 象 的 副本 


= 
里 . 








5) AVAILABLE: 当前 处 于 可 用 状态 的 Pod 对 象 的 副本 数量 ， 即 可 
正常 提供 服务 的 副本 数 。 


6) AGE: Pod 的 存在 时 长 。 


@ Deployment 资 源 对 象 通过 ReplicaSet 控 制 器 实例 完成 对 
Pod 对 象 的 控制 ， 而 非 直 接 控制 。 男 外 ， 通 过 控制 器 创建 的 Pod 对 象 都 会 
被 自动 附加 一 个 标签 ， 其 格式 为 “run=<Controller_Name>”， 例 如 ， 上 面 
, $9 创建 的 Pod， 会 拥有 “run=myapp” 标 签 。 后 面 的 章节 对 此 会 有 详 
细 摘 述 。 





而 此 Deployment 探 制 器 创建 的 唯一 Pod 对 象 运 行 正 常 与 否 ， 其 被 调 
度 至 哪个 节点 运行 ， 当 前 是 否 就 绪 等 也 是 用 户 在 创建 完成 后 应 该 重点 关 
注 的 信息 。 由 控制 器 创建 的 Pod 对 象 的 名 称 通常 是 以 控制 器 名 称 为 前 
级 ， 以 随机 字符 为 后 经， 例如， 下 面 命令 输出 结果 中 的 myapp- 
6865459dff-5nsjc: 





$ kubectl1 get pods -0 wide 

NAME READY _ STATUS RESTARTS AGE IP NODE 

myapp-6865459dff-5nsjc 1/1 Running 0 3m 10.244.3.2 node03. 
ilinux.io 





上 面 命令 的 执行 结果 中 ， 每 一 个 字段 均 代表 着 Pod 资 源 对 象 一 个 方 
面 的 属性 ， 除 了 NAME 之 外 的 其 他 字段 及 功用 说 明 如 下 。 


(DREADY: Pod 中 的 容器 进程 初始 化 完成 并 能 够 正常 提供 服务 时 即 
为 就 绪 状 态 ， 此 字段 用 于 记录 处 于 就 绪 状 态 的 容 吉 数量 。 


CSTATUS: Pod 的 当前 状态 ， 其 值 可 能 是 Pending、Running、 
Succeeded、Failed 和 Unknown 等 其 中 之 一 。 


(BRESTARTS: Pod 对 象 可 能 会 因 容 器 进程 骨 尝 、 超 出 资源 限额 等 
原因 发 生 故 障 问题 而 被 重启 ， 此 字段 记录 了 它 重启 的 次 数 。 


(WIP: Pod 的 IP 地 址 ， 其 通常 由 网 络 插件 自动 分 配 。 


GNODE: 创建 时 ，Pod 对 象 会 由 调度 器 调度 至 集群 中 的 某 节 点 运 
行 ， 此 字段 即 为 节点 的 相关 标识 信息 。 





名 提示 ”如 果 指 定名 称 空间 中 存在 大 量 的 Pod 对 象 而 使 得 类 似 媳 
上 命令 的 输出 结果 存在 太 多 的 不 相关 信息 时 ， 则 可 通过 指定 选项 “-] 
run=myapp” 进 行 Pod 对 象 过 滤 ， 其 仪 显示 符合 此 标签 选择 器 的 Pod 对 象 。 


确认 Pod 对 象 已 转 为 “Running” 状 态 之 后 ， 即 可 于 集群 中 的 任 一 节点 
(或 其 他 Pod 对 象 〉 和 直接 访问 其 容 右 化 应 用 中 的 服务 ， 如 图 2-11 中 节 点 
NodeX 上 的 客户 端 程序 Client， 或 者 集群 上 运行 于 Pod 中 的 客户 端 程序 。 


kubect 





| Kubernetes ; 
I Cluster 


default namespace 


Label Client 


Selector 


‘ 
a 


图 2-11 访问 Pod 中 容 占 化 应 用 服务 程序 


例如 ， 在 集群 中 任 一 节点 上 使 用 curl 命 令 对 地 址 为 10.244.3.2 的 Pod 
对 象 myapp-6865459dff-5nsjc 的 80 端 口 发 起 服务 请 求 ， 命 令 及 结果 如 下 所 
个 \: 





[ik8s@node03 ~]$ curl http://10.244.3.2:80/ 
Hello MyApp | Version: vi | <a href="hostname.html">Pod Name</a> 





2.4.2 ”探查 Pod 及 应 用 详情 


资源 创建 或 运行 过 程 中 偶尔 会 因 故 出 现 异 帝 ， 此 时 用 户 需 要 充分 获 
取 相 关 的 状态 及 配置 信息 以 便 确 定 问题 的 所 在 。 另 外 ， 在 对 资源 对 象 进 
行 创建 或 修改 完成 之 后 ， 也 需要 通过 其 详细 的 状态 来 了 解 操作 成 功 与 
个 。kubectlt 有 多 个 子 命令 可 用 于 从 不 同 的 角度 显示 对 象 的 状态 信息 ， 这 
些 信息 有 助 于 用 户 了 解 对 象 的 运行 状态 、 属 性 详情 等 信息 。 


1) kubectl describe: 显示 资源 的 详情 ， 包 括 运行 状态 、 事 件 等 信 
妨 ， 但 不 同 的 资源 类 型 其 输出 内 容 不 尽 相 同 。 


2) kubectl logs: 但 看 Pod 对 象 中 容器 输出 在 控制 台 的 日 志 信 息 。 在 
Pod 中 运行 有 多 个 容器 时 ， 需 要 使 用 选项 “-c” 指 定 容器 名 称 。 


3) kubectl exec: 在 Pod 对 象 某 容器 内 运行 指定 的 程序 ， 其 功能 类 似 
于 “docker exec” 命 令 ， 可 用 于 了 解 容器 各 方面 的 相关 信息 或 执行 必 和 需 的 
设 定 操作 等 ， 其 具体 功能 取决 于 容器 内 可 用 的 程序 。 


1. 查 看 Pod 对 象 的 详细 描述 
下 面 给 出 的 命令 打印 了 此 前 由 myapp 创 建 的 Pod 对 象 的 详细 状态 信 


息 ， 为 了 便于 后 续 的 多 次 引用 ， 这 里 先 将 其 名 称 保存 于 变量 
POD NAME 中。 命令 的 执行 结果 中 省 略 了 部 分 输出 : 























~]$ POD_NAME=myapp-6865459dff-5nsjc 
~]$ kubect1l describe pods $POD_NAME 


Name : myapp-6865459dff-5nsjc 
Namespace: default 
Priority: 0 
PriorityClassName: <none> 
Node: node03.ilinux.io/172.16.0.68 
Status: Running 
IP: 10.244.3.2 
Controlled By: ReplicaSet/myapp-6865459dff 
Containers: 
myapp: 
Events: 
Type Reason Age From Message 


Normal Scheduled 55m default-scheduler Successfully assigned 


default/myapp-6865459dff-S5nsjc to node03.ilinux.io 


Normal Pulling 55m kubelet, node03.ilinux.io pulling image "ikubernetes/ 
myapp:vi" 

Normal Pulled 54m kubelet, node03.ilinux.io Successfully pulled image 
"ikubernetes/myapp:vi1" 

Normal Created 54m kubelet, node03.ilinux.io Created container 

Normal Started 54m kubelet, node03.ilinux.io Started container 








不 同 的 需求 场景 中 ， 用 户 需 要 关注 不 同 纬度 的 输出 ， 但 一 般 来 说 ， 
Events 和 Status 字 段 会 是 重点 关注 的 对 象 ， 它 们 分 别 代 表 了 Pod 对 象 运行 
过 程 中 的 重要 信息 及 当前 状态 。 上 面 命令 执行 结果 中 的 不 少 字 段 都 可 以 
见 名 而 知 义 ， 而 且 部 分 字段 在 前 面 介 绍 其 他 命令 输出 时 已 经 给 出 ， 还 有 
一 部 分 会 在 本 书后 面 的 篇 幅 中 给 予 介 绍 。 

2. 碍 看 容器 日 志 

Docker 容 器 一 般 仅 运 行 单 个 应 用 程序 ， 其 日 志 信 息 将 通过 标准 错误 
输出 等 方式 直接 打印 至 控制 台 , “kubectl logs” 命 令 即 用 于 查看 这 些 日 
志 。 例 如 ， 碍 看 由 Deployment 控 制 器 myapp 创 建 的 Pod 对 象 的 控制 台 日 


志 ， 命 令 如 下 : 








~]$ kubect1 logs $POD_NAME 
10.244.3.1 - - [.....] "GET / HTTP/1.1" 200 65 "-" "curl/7.29.0" "-" 








如 末 Pod 中 运行 有 多 个 容器 ， 则 需要 在 得 看 日 志 时 为 其 使 用 “-c 选 
项 指定 容器 名 称 。 例 如 ， 当 读者 所 部 署 的 是 KubeDNS 附 件 而 非 CoreDNS 
时 ，kube-system 名 称 空间 内 的 kube-dns 相 关 的 Pod 中 同时 运行 着 
kubedns、dnsmasq 和 sidecar 三 个 容器 ， 如 果 要 查看 kubedns 容 器 的 日 志 ， 
需要 使 用 类 似 如 下 的 命令 : 











~]$ DNS_POD=$(kubect] get pods -o name -n kube-system | grep kube-dns) 
~]$ kubectl1 logs $DNS_POD -c kubedns -n kube-system 











需要 注意 的 是 ， 日 志 查 看 命令 仅 能 用 于 打印 存在 于 Kubernetes 系 统 
上 的 Pod 中 容 占 的 日 志 ， 对 于 已 经 删除 的 Pod 对 象 ， 其 容器 日 志 信 息 将 无 
从 获取 。 日志 信 息 是 用 于 辅助 用 户 获 取 容 器 中 应 用 程序 运行 状态 的 最 有 
效 的 途径 之 一 ， 也 是 非常 重要 的 排 错 手段 ， 因 此 通常 需要 使 用 集中 式 的 
日 志 服 务 右 统一 收集 存储 于 各 Pod 对 象 中 容器 的 日 志 信 息 。 








3. 在 容器 中 运行 额外 的 程序 


运行 着 非 交 互 式 进 程 的 容器 中 ， 默 认 运 行 的 唯一 进程 及 其 子 进程 启 
动 后 ， 容 器 即 进 入 独立 、 隔 离 的 运行 状态 。 对 容 右 内 各 种 详情 的 了 解 需 
要 穿 透 容器 边界 进入 其 中 运行 其 他 的 应 用 程序 来 进行 ，“kubect] exec” 可 
以 让 用 户 在 Pod 的 某 容器 中 运行 用 户 所 需要 的 任何 存在 于 容器 中 的 程 
序 。 在 “kubectl logs "获取 的 信 奶 不 够 全 面 时 ， 此 命令 可 以 通过 在 Pod 中 
运行 其 他 指定 的 命令 (前 提 是 容 右 中 存在 此 程序 ) 来 辅助 用 户 获 取 更 多 
的 信息 。 一 个 更 便捷 的 使 用 接口 的 方式 是 直接 交互 式 运 行 容 器 中 的 某 个 
Shell 程 序 。 例 如 ， 直 接 查 看 Pod 中 的 容器 运行 的 进程 : 














~]$ kubectl1 exec $POD_NAME ps aux 
PID USER TIME COMMAND 


1 root 0:00 nginx: master process nginx -g daemon off; 
8 nginx 0:00 nginx: worker process 
9 root 0:00 ps aux 














O 注意 ”如 果 Pod 对 象 中 运行 了 多 个 容器 ， 那 么 在 程序 运行 时 还 
需要 使 用 “-c<container_name>” 选 项 指定 要 于 其 内 部 运行 程序 的 容器 名 
称 。 


藻 要 进入 容器 的 交互 式 Shell 接 口 ， 可 使 用 大 似 如 下 的 合 命令 ， 和 斜体 部 
分 表示 在 容器 的 交互 式 接口 中 执行 的 命令 : 








~]$ kubectl1 -it exec $POD_NAME /bin/sh 

/ # hostname 

myapp-6865459dff-5nsjc 

/ # netstat -tnl 

Active Internet connections (only servers) 

Proto Recv-Q Send-Q Local Address Foreign Address State 

tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 
/# 


| 


2.4.3 部署 Service 对 象 





简单 来 说 ， 一 个 Service 对 象 可 视 作 通过 其 标签 选择 右 过 滤 出 的 一 组 
PodA 象 ， 并 能 够 为 此 组 Pod 对 象 监 昕 的 套 接 字 提供 端口 代理 及 调度 服 


务 
1. 创 建 Service 对 象 


“kubectl expose” 命 令 可 用 于 创建 Service 对 象 以 将 应 用 程序 “ 暴 
露 ”(expose) 于 网 络 中 。 例 如 ， 下 面 的 命令 即 可 将 myapp 创 建 的 Pod 对 
象 使 用 “NodePort" 类 型 的 服务 暴露 到 集群 外 部 : 





~]$ kubect1 expose deployments/myapp --type="NodePort" --port=80 --name=myapp 
service "myapp" exposed 





上 面 的 命令 中 ，--type 选 项 用 于 指定 Service 的 类 型 ， 而 --port 则 用 于 
指定 要 暴露 的 容器 端口 ， 目 标 Service 对 象 的 名 称 为 myapp。 创 建 完成 
后 ，default 名 称 空 间 中 的 对 象 及 其 通信 示意 图 如 图 2-12 所 示 。 








kubectl myapp Clients 







Kubernetes 
Cluster 


default namespace 


区 =]sI=| 
Selector ClusterIP:Port a 
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天 





图 2-12 ”Service 对 象 在 Pod 对 象 前 端 添加 了 一 个 固定 访问 层 





下 面 通过 运行 于 同一 集群 中 的 Pod 对 象 中 的 客户 端 程序 发 起 访问 测 
试 ， 来 模拟 图 2-12 中 的 源 自 myapp Client Pod 对 象 的 访问 请 求 。 首 先 ， 使 
用 kubectl run 命 令 创 建 一 个 Pod 对 象 ， 并 直接 接 入 其 交互 式 接口 ， 如 下 命 
令 的 -it 组 合 选项 即 用 于 交互 式 打开 并 保持 其 shell 命 令 行 接口 ;而 后 通过 
wget 命 令 对 此 前 创建 的 Service 对 象 的 名 称 发 起 访问 请 求 ， 如 下 命令 中 的 
myapp 即 Service 对 象 名 称 ，default 即 其 所 属 的 Namespace 对 象 的 名 称 : 





$ kubect] run client --image=busybox --restart=Never -it -- /bin/sh 
If you don't see a command prompt, try pressing enter. 

/ # wget -0 - -q http://myapp.default:80 

Hello MyApp | Version: vi | <a href="hostname.html">Pod Name</a> 





创建 时 ，Service 对 象 名 称 及 其 ClusterIP 会 由 CoreDNS 附 件 动态 添加 
至 名 称 解析 库 当 中 ， 因 此 ， 名 称 解 析 服 务 在 对 象 创建 后 即 可 直接 使 用 。 


类 似 于 列 出 Deployment 控 制 器 及 Pod 对 象 的 方式 , “kubectl get 


services” 命 令 能 够 列 出 Service 对 象 的 相关 信息 ， 例 如 下 面 的 命令 显示 了 
Service 对 象 myapp 的 简要 状态 信息 : 





~]$ kubectl1 get svc/myapp 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
myapp NodePort 10.109.39.145 <none> 80:31715/TCP 5m 





其 中 ,，“PORT (s) "字段 表明 ， 集 群 中 各 工作 节点 会 捕获 发 往 本 地 
的 目标 端口 为 31715 的 流量 ， 并 将 其 代理 至 当前 Service 对 象 的 80 端 口 ， 
于 是 ， 集 群 外 部 的 用 户 可 以 使 用 当前 集群 中 任 一 节点 的 此 端口 来 请 求 
Service 对 象 上 的 服务 。CLUSTER-IP 字 段 为 当前 Service 的 IP 地 址 ， 它 是 
一 个 虚拟 IP， 并 没有 配置 于 集群 中 的 任何 主机 的 任何 接口 之 上 ， 但 每 个 
node 之 上 的 kube-proxy 都 会 为 CLUSTER-IP 所 在 的 网 络 创 建 用 于 转发 的 
iptables 或 ipvs 规 则 。 此 时 ， 用 户 可 于 集群 外 部 任 一 浏览 器 请 求 集群 任 一 
节点 的 相关 端口 来 进行 访问 测试 。 


创建 Service 对 象 的 另 一 种 方式 是 使 用 “kubectl create service” 命 令 ， 
对 应 于 每 个 类 型 ， 它 分 别 有 一 个 专用 的 子 命令 ， 例 如 “kubectl create 
service clusterip” 和 “kubectl create service nodeport” 和 等， 各 命令 在 使 用 方 


式 上 也 略 有 区 别 。 
2. 人 查看 Service 资 源 对 象 的 描述 
“kubectl describe services” 命 令 用 于 打印 Service 对 象 的 详细 信息 ， 它 


通常 包括 Service 对 象 的 Cluster IP， 关 联 Pod 对 象 时 使 用 的 标签 选择 器 及 
关联 到 的 Pod 资 源 的 端点 等 ， 示 例如 下 : 











~]$ kubectl1 describe services myapp-svc 
Name : myapp 


Namespace: default 

Labels: run=myapp 
Annotations: <none> 
Selector: run=myapp 

Type: NodePort 

IP: 10.109.39.145 
Port: <unset> 80/TCP 
TargetPort : 80/TCP 

NodePort : <unset> 31715/TCP 
Endpoints: 10.244.3.2:80 
Session Affinity: None 

External Traffic Policy: Cluster 

Events: <none> 


一 


上 面 命 令 的 执行 结果 输出 基本 上 可 以 做 到 见 名 而 知 义 ， 此 处 需要 特 
别 说 明 的 几 个 字段 具体 如 下 : 


1) Selector: 当前 Service 对 象 使 用 的 标签 选择 堪 ， 用 于 选择 关联 的 
Pod 对 象 。 


2) Type: 即 Service 的 类 型 ， 其 值 可 以 是 ClusterIP、NodePort 和 
LoadBalancer 等 其 中 之 一 。 


3) IP: 当前 Service 对 象 的 ClusterIP。 
4) Port， 姑 露 的 端口 ， 即 当前 Service 用 于 接收 并 啊 应 请 求 的 端口 。 


5) TargetPort: 容器 中 的 用 于 暴露 的 目标 端口 ， 由 Service Port 路 由 
请 求 至 此 端口 。 

6) NodePort 当前 Service 的 NodePort， 它 是 否 存在 有 效 值 与 Type 
字段 中 的 类 型 相关 。 


7) EndPoints: 后 端 端点 ， 即 被 当前 Service 的 Selector 挑 中 的 所 有 
Pod 的 IP 及 其 端口 。 








8) Session Affinity: 是 否 启 用 会 话 粘 性 。 


9) External Traffic Policy: 外 部 流量 的 调度 策略 。 


2.4.4 扩容 和 纵容 


前 面 示例 中 创建 的 Deployment 对 象 myapp 仪 创建 了 一 个 Pod 对 象 ， 
其 所 能 够 承载 的 访问 请 求 数量 即 受 限于 这 单个 Pod 对 象 的 服务 容量 。 请 
求 流量 上 升 到 接近 或 超出 其 容量 之 前 ， 用 户 可 以 通过 Kubermetes 的 “扩容 
机 制 ”来 扩展 Pod 的 副本 数量 ， 从 而 提升 其 服务 容量 ， 


简单 来 说 ， 所 谓 的 “伸缩 ”〈Scaling) 就 是 指 改变 特定 控制 器 上 Pod 
副本 数量 的 操作 , “扩容 ”(scaling up) 即 为 增加 副本 数量 ， 而 “ 缩 
容 ”(scaling down) 则 意 指 缩减 副本 数量 。 不 过 ， 无 论 是 扩容 还 是 缩 
容 ， 其 数量 都 需要 由 用 户 明 确 给 出 。 


Service 对 象 内 建 的 负载 均衡 机 制 可 在 其 后 端 副本 数量 不 止 一 个 时 目 
动 进行 流量 分 及 ， 它 还 会 自动 监控 关联 到 的 Pod 的 健康 状态 ， 以 确保 仅 
将 请 求 流量 分 及 全 可 用 的 后 疝 Pod 对 象 。 耕 人 尔 Deployment 控 制 占 省 理 包 
含 多 个 Pod 实 例 ， 则 必要 时 用 户 还 可 以 为 其 使 用 “滚动 更 新 "机制 将 其 容 
融 镜 像 升 级 到 新 的 版 本 或 变更 那些 文 持 动态 修改 的 Pod 属 性 。 


使 用 kubectl run 命 令 创 建 Deployment 对 象 时 ,，“--replicas=” 选 项 能 够 
指定 由 该 对 象 创建 或 管理 的 Pod 对 象 副本 的 数量 ， 且 其 数量 文 持 运行 时 
进行 修改 ， 并 立即 生效 。“kubect] scale” 命 令 就 是 专用 于 变动 控制 器 应 用 
规模 的 命令 ， 它 文 持 对 Deployment 资 源 对 象 的 扩容 和 缩 容 操作 。 例 如 ， 
则 可 以 使 用 如 下 命令 来 完 














~]$ kubect1 scale deployments/myapp --replicas=3 
deployment .extensions "myapp" scaled 





而 后 列 出 由 myapp 创 建 的 Pod 副 本 ， 确 认 其 扩展 操作 的 完成 状态 。 
如 下 命令 显示 出 其 Pod 副 本 数量 已 经 扩 增 至 3 个 ， 其 中 包括 此 前 的 myapp- 
6865459dff-5nsjc: 





~]$ kubect1l get pods -1 run=myapp 


NAME READY STATUS RESTARTS AGE 
myapp-6865459dff-52j7t 0/1 ContainerCreating 0 53S 
myapp-6865459dff-5nsjc 1/1 Running 0 2h 


myapp-6865459dff-jz7t6 0/1 ContainerCreating 0 53S 





Deployment 对 象 myapp 规 模 扩 展 完成 之 后 ，default 名 称 空间 中 的 资 
源 对 象 及 其 关联 关系 如 图 2-13 所 示 。 


kubectl myapp Clients 





NodeIP:NodePort' 


Kubernetes ; 





Cluster 


Client 
ClusterIP:Port 


PodIP:80 


图 2-13 ”Deployment 对 象 规模 扩 增 完成 


而 后 由 “kubectl describe deployment” 命 令 打 印 Deployment 对 象 myapp 
的 详细 信息 ， 了 解 其 应 用 规模 的 变动 及 当前 Pod 副 本 的 状态 等 相关 信 
恩 。 从 下 面 的 命令 结果 可 以 看 出 ， 其 Pod 副 本 数量 的 各 项 指标 都 已 经 转 
目标 数量 ， 而 其 事件 信息 中 也 有 相应 的 事件 显示 其 扩 增 操作 
> 动 完成 ， 

















~]$ kubectl1 describe deployments/myapp 

Name : myapp 

selector: run=myapp 

Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 


unavailable 


Type Reason Age From Message 


myapp-6865459dff to 3 





由 myapp 自 动 创 建 的 Pod 资 源 全 都 拥有 同一 个 标签 选择 
器 “run=myapp”， 因 此 ， 前 面 创建 的 Service 资 源 对 象 myapp 的 后 端 端点 
也 已 经 通过 标签 选择 器 自动 扩展 到 了 这 3 个 Pod 对 象 相关 的 端点 ， 如 下 面 
的 命令 结果 及 图 2-13 所 示 : 





~]$ kubectl1 describe services/myapp 
Name: myapp 


Endpoints: 10.244.1.3:80,10.244.2.2:80,10.244.3.2:80 





回 到 此 前 创建 的 客户 端 Pod 对 象 dient 的 交互 式 接口 ， 对 Service 对 象 
myapp 反 复发 起 测试 请 求 ， 即 可 验 正 其 负载 均衡 的 效果 。 由 如 下 命令 及 
其 结果 可 以 看 出 ， 它 会 将 请 求 调度 至 后 端的 各 Pod 对 象 进行 处 理 : 





~]$ / # while true; do wget -0 - -q http://myapp.default:80/hostname.html; 
sleep 1; done 

myapp-6865459dff-jz7t6 

myapp-6865459dff-52j7t 

myapp-6865459dff-5nsjc 





应 用 规模 缩 容 的 方式 与 扩容 相似 ， 只 不 过 是 将 Pod 副 本 的 数量 调 至 
比 原来 小 的 数字 即 可 。 例 如 ， 将 myapp 的 Pod 副 本 缩减 至 2 个 ， 可 以 使 用 
如 下 命令 进行 : 





~]$ kubect1 scale deployments/myapp --replicas=2 
deployment .extensions "myapp" scaled 





至 此 ， 功 能 基本 完整 的 容器 化 应 用 已 在 Kubernetes 上 部 晋 完 成 ， 即 
的 分 层 应 用 也 只 需要 通过 合适 的 镜像 以 类 似 的 方式 就 能 
部 署 完成 。 





2.4.5 “修改 及 删除 对 象 


成 功 创建 于 Kubernetes 之 上 的 对 象 也 称 为 活动 对 象 (live object) ， 
其 配置 信息 (ive object configuration ) 由 API Server 保 存 于 集群 状态 存 
储 系统 etcd 中 , “kubectl get TYPE NAME-o yaml 命 令 可 获取 到 相关 的 完 
整 信息 ， 而 运行 “kubectl edit" 命 令 可 调用 默认 编辑 器 对 活动 对 象 的 可 配 
置 属性 进行 编辑 。 人 例如， 修改 此 前 创建 的 Service 对 象 myapp 的 类 型 为 
ClusterIP， 使 用 “kubectl edit service myapp” 命 令 打 开 编 辑 界 面 后 修改 type 
属性 的 值 为 ClusterIP， 并 删除 NodePort 属 性 ， 然 后 保存 即 可 。 对 活动 对 
象 的 修改 将 实时 生效 ， 但 资源 对 象 的 有 些 属性 并 不 支持 运行 时 修改 ， 此 
种 情况 下 ， 编 辑 器 将 不 允许 保存 退出 。 

有 些 命令 是 kubectl edit 命 令 某 一 部 分 功能 的 二 次 封装 ， 例 如 ， 
kubectl scale 命 令 不 过 是 专用 于 修改 资源 对 象 的 replicas 属 性 值 而 已 ， 它 
也 同样 直接 作用 于 活动 对 象 。 


不 再 有 价值 的 活动 对 象 可 使 用 “kubectl delete” 命 令 予 以 删除 ， 需 要 
删除 Service 对 象 myapp 时 ， 使 用 如 下 命令 即 可 完成 : 








~]$ kubectl1 delete service myapp 
service "myapp" delete 





有 了 时候 需要 清空 某 一 类 型 下 的 所 有 对 象 ， 只 需要 将 上 面 命令 对 象 的 
名 称 换 成 <--all? 选 项 便 能 实现 。 例 如 ， 删 除 默认 名 称 空 间 中 所 有 的 
Deployment 控 制 器 的 命令 如 下 : 








~]$ kubectl1 delete deployment --all 
deployment .extensions "myapp" deleted 














需要 注意 的 是 ， 受 控 于 控制 器 的 Pod 对 象 在 删除 后 会 被 重建 ， 删 除 
此 类 对 象 需要 直接 删除 其 控制 器 对 象 。 不 过 ， 删 除 控制 右 时 知 不 想 删 除 
其 Pod 对 象 ， 可 在 删除 命令 上 使 用 “--cascade=false” 选 项 。 


虽然 直接 命令 式 管 理 的 相关 功能 强大 且 适 合用 于 操纵 Kubernetes 资 
源 对 象 ， 但 其 明显 的 缺点 是 缺乏 操作 行为 以 及 待 运行 对 象 的 可 信 源 。 另 





外 ， 直 接 命 令 式 管理 资源 对 象 存在 较 大 的 局 限 性 ， 它 们 在 设置 资源 对 象 
属性 方面 提供 的 配置 能 力 相 当 有 限 ， 而 且 还 有 不 少 资 源 并 不 支持 命令 操 
作 进行 创 建 ， 例 如 ， 用 户 无 法 创建 带 有 多 个 容 右 的 Pod 对 象 ， 也 无 法 为 
Pod 对 象 创建 存储 卷 。 因 此 ， 管 理 资 源 对 象 更 有 效 的 方式 是 基于 保存 有 
对 象 配 置信 息 的 配置 清单 来 进行 











2.5 ”本 章 小 结 


本 章 着 重 介 绍 了 Kubernetes 的 三 个 核心 资源 抽象 Pod、Deployment 和 
Service， 并 在 介绍 了 kubectl 的 基本 用 法 之 后 通过 案例 讲解 了 如 何在 集群 
中 部 辕 、 虞 露 、 访 问 及 扩 缩 容 容器 化 应 用 ， 具 体 如 下 。 


.Pod 是 运行 容器 化 应 用 及 调度 的 原子 单元 ， 同 一 个 Pod 中 可 同时 运 
行 多 个 容器 ， 这 些 容器 共享 Mount、UTS 及 Network 等 Linux 内 核 名 称 空 
间 ， 并 且 能 够 访问 同一 组 存储 卷 。 


`Deployment 是 最 常见 的 无 状态 应 用 的 控制 器 ， 它 文 持 应 用 的 扩 缩 
容 、 滚 动 更 新 等 操作 ， 为 容器 化 应 用 赋予 了 极 具 弹性 的 功能 。 


“Service 为 弹性 变动 旦 存在 生命 周期 的 Pod 对 象 提供 了 一 个 固定 的 访 
问 接口 ， 用 于 服务 发 现 和 服务 访问 。 


:kubectl 是 Kubernetes API Server 最 常用 的 客户 端 程序 之 一 ， 它 功能 
强大 ， 特 性 丰富 ， 几 乎 能 够 完成 除了 安装 部 署 之 外 的 所 有 管理 操作 。 








第 3 章 ”资源 管理 基础 


Kubernetes 系 统 的 API Server 基 于 HTTP/HTTPS 接 收 并 响应 客户 端的 
操作 请 求 ， 它 提供 了 一 种 “基于 资源 ”(resource-based) 的 RESTful 风 格 
的 编程 接口 ， 将 集群 的 各 种 组 件 都 抽象 成 为 标准 的 REST 资 源 ， 如 
Node、Namespace 和 Pod 等 ， 并 文 持 通 过 标准 的 HITP 方 法 以 JSON 为 数 
7 本 章 将 着 重 描述 Kubernetes 的 资源 管 
理 方式 。 


3.1 资源 对 象 及 API 群 组 


REST 是 Representational State Transfer 的 缩写 ， 意 为 “表征 状态 转 
移 ”， 它 是 一 种 程序 架构 风格 ， 基 本 元 素 为 资源 〈resource) 、 表 征 
Crepresentation ) 和 行为 (action) 。 资 源 即 对 象 ， 一 个 资源 通常 意味 着 
一 个 附 帝 类 型 和 关联 数据 、 文 持 的 操作 方法 以 及 与 其 他 对 象 的 关系 的 对 
象 ， 它 们 是 持 有 状态 的 事物 ， 即 REST 中 的 S 〈State) 。REST 组 件 通过 
使 用 “表征 ”来 捕获 资源 的 当前 或 预期 状态 并 在 组 件 之 间 传 输 该 表征 从 而 
对 资源 执行 操作 。 表 征 是 一 个 字 厄 序列 ， 由 数据 、 描 述 数 据 的 元 数据 以 
及 侦 尔 描述 元 数据 的 元 数据 组 成 (通常 用 于 验证 消 恩 的 完整 性 ) ， 表 征 
还 有 一 些 其 他 常用 但 不 太 精 确 的 名 称 ， 如 文档 、 文 件 和 HTTP 消 轧 实 体 
等 。 表 征 的 数据 格式 称 为 媒体 类 型 (media type，〉， 常 用 的 有 JSON 或 
XML。API 客 户 并 不 能 直接 访问 资源 ， 它 们 需要 执行 “动作 ”(action) 来 
0 
一 种 形式 。 


资源 可 以 分 组 为 集合 (collection) ， 每 个 集合 只 包含 单一 类 型 的 资 
源 ， 并 且 各 资源 间 是 无 序 的 。 当 然 ， 资 源 也 可 以 不 属于 任何 集合 ， 它 们 
称 为 单 体 资 源 。 事 实 上， 集合 本 身 也 是 资源 ， 它 可 以 部 署 于 全 局 级 别 ， 
位 于 API 的 顶层 ， 也 可 以 包含 于 某 个 资源 中 ， 表 现 为 * 子 集合 ”。 集 合 、 
资源 、 子 集合 及 子 资源 间 的 关系 如 图 3-1 所 示 。 
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图 3-1 集合 、 资 源 和 子 资源 


Kubernetes 系 统 将 一 切 事物 都 抽象 为 API 资 源 ， 其 遵循 REST 架 构 风 
格 组 织 并 管理 这 些 资 源 及 其 对 象 ， 同 时 还 支持 通过 标准 的 HTTP 方 法 
(POST、PUT、PATCH、DELETE 和 GET) 对 资源 进行 增 、 删 、 改 、 
查 等 管理 操作 。 不 过 ， 在 Kubernetes 系 统 的 语 境 中 , “资源 * 用 于 表示 “对 
象 ” 的 集合 ， 例 如 ，Pod 资 源 可 用 于 摘 述 所 有 Pod 类 型 的 对 象 ， 但 本 书 将 
不 加 区 别 地 使 用 资源 、 对 象 和 资源 对 象 ， 并 将 它们 统统 理解 为 资源 类 型 
生成 的 实例 一 对 象 。 





3.1.1 Kubernetes 的 资源 对 象 


依据 资源 的 主要 功能 作为 分 类 标准 ，Kubernetes 的 API 对 象 大 体 可 分 
为 工作 负载 (Workload) 、 发 现 和 负载 均衡 (Discovery&LB) 、 配 置 
和 存储 CConfig&Storage ) 、 和 集群 《Cluster) 以 及 元 数据 (Metadata) 
五 个 类 别 。 它 们 基本 上 都 是 围绕 一 个 核心 目的 而 设计 : 如 何 更 好 地 运行 
和 丰富 Pod 资 源 ， 从 而 为 容器 化 应 用 提供 更 灵活 、 更 完善 的 操作 与 管理 
组 件 ， 如 图 3-2 所 示 。 
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图 3-2 ”Kubernetes 常 用 资源 对 象 


工作 负载 型 资源 用 于 确保 Pod 资 源 对 象 能 够 更 好 地 运行 容 占 化 应 
用 ， 有 共有 同一 种 负载 的 各 Pod 对 象 需要 以 负载 均衡 的 方式 服务 于 各 请 
求 ， 而 各 种 容器 化 应 用 彼此 之 间 需 要 彼此 “发 现 ” 以 完成 工作 协同 。Pod 
资源 具有 生命 周期 ， 存 储 型 资源 能 够 为 重 构 的 Pod 对 象 提供 持久 化 的 数 
据 存储 机 制 ， 共 享 同一 配置 的 Pod 资 源 可 从 配置 型 资源 中 统一 获取 配置 
改动 信息 ， 这 些 资源 作为 配置 中 心 为 管理 容器 化 应 用 的 配置 文件 提供 了 
极为 便捷 的 管理 机 制 。 集 群 型 资源 为 管理 集群 本 身 的 工作 特性 提供 了 配 
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置 接口 ， 而 元 数据 型 资源 则 用 于 配置 集群 内 部 的 其 他 资源 的 行为 。 
(1) 工作 负载 型 资源 


Pod 是 工作 负载 型 资源 中 的 基础 资源 ， 它 负责 运行 容器 ， 并 为 其 解 
决 环境 性 的 依赖 ， 例 如 ， 回 容器 注入 共有 吾 的 或 持久 化 的 存储 卷 、 配 置信 
县 或 密 钥 数据 等 。 但 Pod 可 能 会 因为 资源 超 限 或 节点 故障 等 原因 而 终 
止 ， 这 些 非 下 第 终止 的 Pod 资 源 需 要 被 重建 ， 不 过 ， 这 类 工作 将 由 工作 
负载 型 的 控制 占 来 完成 ， 它 们 通常 也 称 为 pod 控 制 右 。 


应 用 程序 分 为 无 状态 和 有 状态 两 种 类 型 ， 它 们 对 环境 的 依赖 及 工 
作 特 性 有 很 大 的 不 同 ， 因 此 分 属 两 种 不 同类 型 的 Pod 控 制 右 来 管理 ， 
ReplicationController、ReplicaSet 和 Deployment 负 责 管理 无 状态 应 用 ， 
StatefulSet 用 于 管控 有 状态 类 应 用 。ReplicationController 是 上 一 代 的 控制 
器 ， 其 功能 由 ReplicaSet 和 Deployment 负 责 实现 ， 因 此 几 近 于 废弃 。 还 
有 些 应 用 较为 独特 ， 它 们 需要 在 集群 中 的 每 个 节点 上 运行 单个 Pod 资 
源 ， 负 贡 收 集 日 志 或 运行 系统 服务 等 任务 ， 这 些 Pod 资 源 的 管理 则 属于 
DaemonSet 控 制 器 的 分 内 之 事 。 男 外 ， 有 些 容器 化 应 用 需要 继续 运行 以 
为 守护 进程 不 间断 地 提供 服务 ， 而 有 些 则 应 该 在 正常 完成 后 退出 ， 这 些 
在 正常 完成 后 就 应 该 退出 的 容器 化 应 用 则 由 Job 控 制 器 负责 管控 。 下 面 
是 各 Pod 控 制 器 更 为 详细 的 说 明 。 


.ReplicationController: 用 于 确保 每 个 Pod 副 本 在 任 一 时 刻 均 能 满足 
目标 数量 ， 换 言 之 ， 它 用 于 保证 每 个 容器 或 容器 组 总 是 运行 并 且 可 访 
问 ;， 它 是 上 一 代 的 无 状态 Pod 应 用 控制 嚣 ， 建 议 读者 使 用 新 型 控制 右 
Deployment 和 ReplicaSet 来 取代 它 。 
































.ReplicaSet:， 新 一 代 ReplicationController， 它 与 ReplicationController 
的 唯一 不 同 之 处 仅 在 于 文 持 的 标签 选择 器 不 同 ，ReplicationController 只 
支持 等 值 选择 器 ， 而 ReplicaSet 还 额外 支持 基于 集合 的 选择 器 。 


“Deployment: 用 于 管理 无 状态 的 持久 化 应 用 ， 例 如 HTTP 服 务 器 ; 
它 用 于 为 Pod 和 ReplicaSet 提 供 声明 式 更 新 ， 是 建构 在 ReplicaSet 之 上 的 
更 为 高 级 的 控制 器 。 


'StatefulSet: 用 于 管理 有 状态 的 持久 化 应 用 ， 如 database 服 务 程序 ; 
其 与 Deployment 的 不 同 之 处 在 于 StatefulSet 会 为 每 个 Pod 创 建 一 个 独 有 的 
持久 性 标识 符 ， 并 会 确保 各 Pod 之 间 的 顺序 性 。 











DaemonSet: 用 于 确保 每 个 节点 都 运行 了 某 Pod 的 一 个 副本 ， 新 增 
的 节点 一 样 会 被 添加 此 类 Pod;， 在 市 点 移 除 时 ， 此 类 Pod 会 个 回收 ; 
DaemonsSet 和 党 用 于 运行 集群 存储 守护 进程 一 如 glusterd 和 ceph， 还 有 日 志 
收集 进程 一 如 fluentd 和 ]ogstash， 以 及 监控 进程 一 如 Prometheus 的 Node 
Exporter、collectd、Datadog agent 和 Ganglia 的 gmond 等 。 


:Job: 用 于 管理 运行 完成 后 即 可 终止 的 应 用 ， 例 如 批 处 理 作 业 任 
务 ; 换 句 话 讲 ，Job 创 建 一 个 或 多 个 Pod， 并 确保 其 符合 目标 数量 ， 直 到 
Pod 正 常 结束 而 终止 。 


(2) 发现 和 负载 均衡 


Pod 资 源 可 能 会 因为 任何 意外 故障 而 被 重建 ， 于 是 它 需 要 固定 的 可 
被 “发 现 ?的 方式 。 另 外 ，Pod 资 源 仅 在 集群 内 可 见 ， 它 的 客户 端 也 可 能 
是 集群 内 的 其 他 Pod 资 源 ， 知 要 开放 给 外 部 网 络 中 的 用 户 访 问 ， 则 需要 
事先 将 其 暴露 到 集群 外 部 ， 并 且 要 为 同一 种 工作 负载 的 访问 流量 进行 负 
载 均衡 。Kubernetes 使 用 标准 的 资源 对 象 来 解决 此 类 问题 ， 它 们 是 用 于 
为 工作 负载 添加 发 现 机 制 及 负载 均衡 功能 的 Service 资 源 和 Endpoint 资 
源 ， 以 及 通过 七 层 代 理 实现 请 求 流量 负载 均衡 的 Ingress 资 源 。 


(3) 配置 与 存储 


Docker 容 器 分 层 联 合 挂 载 的 方式 决定 了 不 宜 在 容器 内 部 存储 需要 持 
久 化 的 数据 ， 于 是 它 通 过 引入 挂 载 外 部 存储 卷 的 方式 来 解决 此 类 问题 ， 
而 Kubernetes 则 为 此 设计 了 Volume 资 源 ， 它 文 持 众多 类 型 的 存储 设备 或 
存储 系统 ， 如 GlusterFS、CEPH RBD 和 Flocker 等 。 另 外 ， 新 版 本 的 
Kubernetes 还 支持 通过 标准 的 CSI (Container Storage Interface ) 统一 存储 
接口 以 及 扩展 文 持 更 多 类 型 的 存储 系统 。 


另外 ， 基 于 镜像 构建 容器 应 用 时 ， 其 配置 信息 于 镜像 制作 时 烧 入 ， 
从 而 为 不 同 的 环境 定制 配置 就 变 得 较为 困难 。Docker 使 用 环境 变量 等 作 
为 解决 方案 ， 但 这 么 一 来 就 得 于 容器 启动 时 将 值 传 入 ， 且 无 法 在 运行 时 
修改 。ConfigMap 资 源 能 够 以 环境 变量 或 存储 卷 的 方式 接 入 到 Pod 资 源 的 
容 嚣 中， 并且 可 被 多 个 同类 的 Pod 共 享 引 用 ， 从 而 实现 “一 次 修改 ， 多 处 
生效 ”。 不 过 ， 这 种 方式 不 适 于 存储 敏感 数据 ， 如 私 钥 、 密 码 等 ， 那 是 
男 一 个 资源 类 型 Secret 的 功能 。 


(4) 集群 级 资源 
































Pod、Deployment、Service 和 ConfigMap 等 资源 属于 名 称 空间 级 别 ， 
可 由 相应 的 项 目 管理 员 所 管理 。 然 而 ，Kubernetes 还 存在 一 些 集群 级 别 
的 资源 ， 用 于 定义 集群 自身 配置 信息 的 对 象 ， 它 们 仪 应 该 由 集群 管理 员 
进行 操作 。 集 群 级 资源 主要 包含 以 下 几 种 类 型 。 


.Namespace: 资源 对 象 名 称 的 作用 范围 ， 绝 大 多 数 对 象 都 隶属 于 某 
个 名 称 空间 ， 默 认 时 隶属 于 “default”。 


.Node: Kubernetes 集 群 的 工作 节点 ， 其 标识 符 在 当前 集群 中 必须 是 
唯一 的 。 


.Role: 名 称 空 间 级 别 的 由 规则 组 成 的 权限 集合 ， 可 被 RoleBinding 
引用 。 


ClusterRole: Cluster 级 别 的 由 规则 组 成 的 权限 集合 ， 可 被 
RoleBinding 和 ClusterRoleBinding 引 用 。 


RoleBinding: 将 Role 中 的 许可 权限 绑 定 在 一 个 或 一 组 用 户 之 上 ， 
它 隶 属于 且 仅 能 作用 于 一 个 名 称 空 间 ; 绑 定时 ， 可 以 引用 同一 名 称 空间 
中 的 Role， 也 可 以 引用 全 局 名 称 空间 中 的 ClusterRole。 


ClusterRoleBinding: 将 ClusterRole 中 定义 的 许可 权限 绑 定 在 一 个 或 
一 组 用 户 之 上 ; 它 能 够 引用 全 局 名 称 空 间 中 的 ClusterRole， 并 能 通过 
Subject 添 加 相关 信息 。 


(5) 元 数据 型 资源 


此 类 资源 对 象 用 于 为 集群 内 部 的 其 他 资源 配置 其 行为 或 特性 ， 如 
HorizontalPodAutoscaler 资 源 可 用 于 自动 伸缩 工作 负载 类 型 的 资源 对 象 的 
规模 ，Pod 模 板 资 源 可 用 于 为 pod 资 源 的 创建 预制 模板 ， 而 LimitRange 则 
可 为 名 称 空间 的 资源 设置 其 CPU 和 内 存 等 系统 级 资源 的 数量 限制 等 。 








@ ,二 一 个 应 用 通常 需要 多 个 资源 的 支撑 ， 例 如 ， 使 用 
Deployment 资 源 管 理应 用 实例 (Pod) 、 使 用 ConfigMap 资 源 保存 应 用 配 
置 、 使 用 Service 或 Ingress 资 源 暴 露 服 务 、 使 用 Volume 资 源 提供 外 部 存储 
等 


本 书后 面 篇 幅 的 主体 部 分 就 展开 介绍 这 些 资 源 类 型 ， 它 们 是 将 容器 
化 应 用 托管 运行 于 Kubernetes 集 群 的 重要 工具 组 件 。 


3.1.2 ”资源 及 其 在 API 中 的 组 织 形式 


在 Kubernetes 上， 资源 对 象 代 表 了 系统 上 的 持久 类 实体 ，Kubernetes 
用 这 些 持 久 类 实体 来 表达 集群 的 状态 ， 包 插 容器 化 的 应 用 程序 正 运 行 于 
哪些 节点 ， 每 个 应 用 程序 有 哪些 资源 可 用 ， 以 及 每 个 应 用 程序 各 自 的 行 
为 策略 ， 如 重启 、 升 级 及 容错 策略 等 。 一 个 对 象 可 能 会 包含 多 个 资源 ， 
用 户 可 对 这 些 资源 执行 增 、 删 、 改 、 查 等 管理 操作 。Kubernetes 通 常 利 
用 标准 的 RESTful 术 语 来 描述 API 概 念 。 


资源 类 型 〈resource type) 是 指 在 URL 中 使 用 的 名 称 ， 如 Pod、 
Namespace 和 Service 等 ， 其 URL 格 式 
为 “GROUP/VERSIONVRESOURCE”， 如 apps/vl/deployment。 


“所 有 资源 类 型 都 有 一 个 对 应 的 JSON 表 示 格 式 ， 称 为 “种 
类 ”(kind) ; 客户 端 创建 对 象 必须 以 JSON 提 交 对 象 的 配置 信息 。 


隶属 于 同一 种 资源 类 型 的 对 象 组 成 的 列表 称 为 “ 集 


合 ”(collection ) ， 如 PodList。 


: 某 种 类 型 的 单个 实例 称 为 “资源 ”(resource) 或 “对 象 ”(object) ， 
如 名 为 pod-demo 的 Pod 对 象 。 


kind 代 表 着 资源 对 象 所 属 的 类 型 ， 如 Namespace、Deployment、 
Service 及 Pod 等 ， 而 这 些 资源 类 型 大 体 又 可 以 分 为 三 个 类 别 ， 具 体 如 
is 








.对 象 〈Object) 类 : 对 象 表示 Kubernetes 系 统 上 的 持久 化 实体 ， 一 
个 对 象 可 能 包含 多 个 资源 ， 客 户 端 可 用 它 执行 多 种 操作 。Namespace、 
Deployment、Service 及 Pod 等 都 属于 这 个 类 别 。 


:列表 (List〉 类: 列表 通常 是 指 同 一 类 型 资源 的 集合 ， 如 
PodLists、NodeLists 等 。 


-人 简单 (Simple〉 类 : 常用 于 在 对 象 上 执行 某 种 特殊 操作 ， 或 者 管理 
韭 持久 化 的 实体 ， 如 /binding 或 /status 等 。 








Kubernetes 绝 大 多 数 的 API 资 源 类 型 都 是 “对 象 ”， 它 们 代表 着 集群 中 
某 个 概念 的 实例 。 有 一 小 部 分 的 API 资 源 类 型 为 “虚拟 ”(virtual〉 类 型 ， 
它们 用 于 表达 一 类 “操作 ”(operation，〉。 所 有 的 对 象 型 资源 都 拥有 一 个 
独 有 的 名 称 标识 以 实现 其 早 等 的 创建 及 获取 操作 ， 不 过 ， 虚 拟 型 资源 无 
须 获 取 或 不 依赖 于 过 等 性 时 也 可 以 不 使 用 专用 标识 符 。 


有 些 资源 类 型 隶属 于 集群 范畴 ， 如 Namespace 和 PersistentVolume， 
而 多 数 资源 类 型 则 受 限 于 名 称 空间 ， 如 Pod、Deployment 和 Service 等 。 
名 称 空 间 级 别 的 资源 的 URL 路 径 中 含有 其 所 属 空 间 的 名 称 ， 这 些 资 源 对 
象 在 名 称 空 间 被 删除 时 会 被 一 并 删除 ， 并 且 这 些 资源 对 象 的 访问 也 将 受 
控 于 其 所 属 的 名 称 空间 级 别 的 授权 审查 。 


Kubernetes 将 API 分 割 为 多 个 逻辑 组 合 ， 称 为 API 群 组 ， 它 们 支持 单 
独 启用 或 禁用 ， 并 能 够 再 次 分 解 。API Server 支 持 在 不 同 的 群 组 中 使 用 
不 同 的 版 本 ， 人 允许 各 组 以 不 同 的 速度 演进 ， 而 且 也 文 持 同一 群 组 同时 存 
在 不 同 的 版 本 ， 如 apps/v1、apps/vlbeta2 和 apps/vlbetal， 也 因此 能 够 在 
不 同 的 群 组 中 使 用 同名 的 资源 类 型 ， 从 而 能 在 稳定 版 本 的 群 组 及 新 的 实 
验 群 组 中 以 不 同 的 特性 同时 使 用 同一 个 资源 类 型 。 群 组 化 管理 的 API 使 
得 其 可 以 更 轻松 地 进行 扩展 。 当 前 系统 的 API Server 上 的 相关 信息 可 通 
过 “kubectl api-versions” 命 令 获 取 。 命 令 结果 中 显示 的 不 少 API 群 组 在 后 
续 的 章节 中 配置 资源 清单 时 会 多 次 用 到 : 











[root@master ~]# kubectl] api-versions 
admissionregistration.k8s.io/vibetali 
apiextensions.k8s.io/vibeta1i 
apiregistration.k8s.io/vi 
apiregistration.k8s.io/vibetal 
apps/vi1 

apps/vibetali 

apps/vibeta2 
authentication.k8s.io/vi 
authentication.k8s.io/vibetali 
authorization.k8s.io/vi 
authorization.k8s.io/vibeta1 
autoscaling/v1i 
autoscaling/v2betal 

batch/vi 

batch/vibeta1 
certificates.k8s.io/vibetali 
events.k8s.io/vibetai 
extensions/vibetal1 
networking.k8s.io/vi1 
policy/vibetal1 
rbac.authorization.k8s.io/vi1 
rbac.authorization.k8s.io/vibetali 
scheduling.k8s.io/vibetal 
storage.k8s.io/v1 


Storage,k8s.1Io/v1betal 
v1 





Kubernetes 的 API 以 层级 结构 组 织 在 一 起 ， 每 个 API 群 组 表现 为 一 个 
以 “/apis” 为 根 路 径 的 REST 路 径 ， 不 过 核心 群 组 core 有 一 个 专用 的 简化 路 
径 “/api/v1”。 目 前 ， 常 用 的 API 群 组 可 归 为 如 下 两 类 。 


-核心 群 组 (core group) : REST 路 径 为 /api/lv1， 在 资源 的 配置 信息 
apiVersion 字 段 中 引用 时 可 以 不 指定 路 径 ， 而 仅 给 出 版 本 ， 


如 “apiVersion: v1”。 


.命名 的 群 组 Cnamed group) : REST 路 径 
为 /apis/$GROUP_NAME/$VERSION， 例 如 /apis/apps/Vv1， 它 在 
apiVersion 字 上 段 中 引用 的 格式 为 “apiVersion: 
$GROUP_NAME/$VERSION”, 如 “apiVersion: apps/V1”。 


总 结 起 来 ， 名 称 空间 级 别 的 每 一 个 资源 类 型 在 API 中 的 URL 路 径 表 
示 都 可 简单 抽象 为 形 
如 “/apis/<group>/<version>/namespaces/<namespace>/<kind-plural>” 的 路 
径 ， 如 default 名 称 空 间 中 Deployment 类 型 的 路 径 
为 /apis/apps/V1/namespaces/default/deployments， 通 过 此 路 径 可 获取 到 
default 名 称 空间 中 所 有 Deployment 对 象 的 列表 : 





~]$ kubectl get --raw /apis/apps/vi/namespaces/default/deployments | jd ， 
{ 


"kind": "DeploymentList", 
"apiVversion": "apps/vi1", 








男 外 ，Kubernetes 还 支持 用 户 自 定义 资源 类 型 ， 目 前 常用 的 方式 有 
三 种 : 一 是 修改 Kubernetes 源 代码 自 定义 类 型 ， 二 是 创建 一 个 自 定义 的 
API Server， 并 将 其 聚合 至 集群 中 ; 三 是 使 用 目 定 义 资源 〈Custom 
Resource Definition, CRD) 。 





3.1.3 ”访问 Kubernetes REST API 


以 编程 的 方式 访问 Kubernetes REST API 有 助 于 了 解 其 流 式 化 的 集群 
管理 机 制 ， 一 种 常用 的 方式 是 使 用 curl 作 为 HITP 客 户 端 直接 通过 API 
Server 在 集群 上 操作 资源 对 象 模拟 请 求 和 啊 应 的 过 程 。 不 过 ， 由 
kubeadm 部 署 的 Kubernetes 集 群 默认 仪 支 持 HTTPS 的 访问 接口 ， 它 需 进 
行 一 系列 的 认证 检查 ， 好 在 用 户 也 可 以 借助 kubectl proxy 命 令 在 本 地 主 
机 上 为 API Server 启 动 一 个 代理 网 关 ， 由 它 文 持 使 用 HTTP 进 行 通 信 ， 其 
工作 逻辑 如 图 3-3 所 示 。 








kubectl 
proxy 


apiserver 





图 3-3 ”kubectl 在 本 地 代理 API Server 


例如 ， 于 本 地 127.0.0.1 的 8080 端 口上 启动 API Server 的 一 个 代理 网 
关 : 





~]$ kubectl1l proxy --port=8080 
Starting to serve on 127.0.0.1:8080 








而 后 即 可 于 另 一 终端 使 用 curl 一 类 的 客户 问 工 具 对 此 和 套 接 字 地 址 发 
起 访问 请 求 ， 例 如 ， 请 求 Kubernetes 集 群 上 的 NamespaceList 资 源 对 象 ， 
即 列 出 集群 上 所 有 的 Namespace 对 象 : 





~]$ curl localhost:8080/api/vi/namespaces/ 
{ 


"kind": "NamespaceList", 
"apiVersion": "v1", 





或 者 使 用 JSON 的 命令 行 处 理 器 jq 命 令 对 啊 应 的 JSON 数 据 流 进行 内 
如 ， 下 面 的 命令 仅 用 于 显示 相关 的 NamespaceList 对 象 中 的 各 
“< 员 对 象 : 





~]$ curl -s localhost:8080/api/vi/namespaces/ | jq .items[].metadata.name 
"default" 

"kube-public" 

"kube-system" 








给 出 特定 的 Namespace 资 源 对 象 的 名 称 则 能 够 直接 获取 相应 的 资源 
信息 ， 以 kube-system 名 称 空间 为 例 : 





~]$ curl -s localhost:8080/api/vi/namespaces/kube-system 


"kind": "Namespace", 
"apiVersion™": "vi1", 
"metadata": { 
"name": "kube-system", 
"selfLink": "/api/vi/namespaces/kube-system", 
"uid": "eb6bf659-9d0e-11e8-bfOd-000c29abof5b", 
"resourceVersion": "33", 
"creationTimestamp": "2018-08-11T02:33:23Z" 
}, 
"spec": { 
"finalizers": [ 
"kubernetes" 


] 


了 
"status": { 
"phase": "Active" 





上 述 命令 响应 的 结果 中 展现 了 Kubermnetes 大 多 数 资 源 对 象 的 资源 配 
置 格 式 ， 它 是 一 个 JSON 序 列 化 的 数据 结构 ， 具 有 kind、apiVersion、 


metadata、spec 和 和 status 五 个 一 级 字段 ， 各 字段 的 意义 和 功能 将 在 3.2 节 中 
重点 介绍 。 





3.2 对象 类 资源 格式 


Kubernetes API 仅 接受 及 响应 JSON 格 式 的 数据 〈JSON 对 象 ) ， 同 
时 ， 为 了 便于 使 用 ， 它 也 允许 用 户 提 供 YAML 格 式 的 POST 对 象 ， 但 API 
Server 需 要 事先 自行 将 其 转换 为 JSON 格 式 后 方 能 提交 。API Server 接 受 
和 返回 的 所 有 JSON 对 象 都 遵循 同一 个 模式 ， 它 们 都 具有 kind 和 
J 用 于 标识 对 象 所 属 的 资源 类 型 、API 群 组 及 相关 的 版 








进一步 地 ， 大 多 数 的 对 象 或 列表 类 型 的 资源 还 需要 具有 三 个 般 套 型 
的 字段 metadata、spec 和 status。 其 中 metadata 字 段 为 资源 提供 元 数据 信 
晨 ， 如 名 称 、 隶 属 的 名 称 空间 和 标签 等 ，spec 则 用 于 定义 用 户 期 望 的 状 
态 ， 不 同 的 资源 类 型 ， 其 状态 的 意义 也 各 有 不 同 ， 例 如 Pod 资 源 最 为 核 
心 的 功能 在 于 运行 容器 ;而 status 则 记录 着 活动 对 象 的 当前 状态 信息 ， 
它 由 Kubernetes 系 统 自行 维护 ， 对 用 户 来 说 为 只 读 字 段 。 


每 个 资源 通常 仪 接受 并 返回 单一 类 型 的 数据 ， 而 一 种 类 型 可 以 被 多 
个 反映 特定 用 例 的 资源 所 接受 或 返回 。 例 如 对 于 Pod 类 型 的 资源 来 说 ， 
用 户 可 创建 、 更 新 或 删除 Pod 对 象 ， 然 而 ， 每 个 Pod 对 象 的 metadata、 
spec 利 status 字 上 段 的 值 却 又 是 各 自 独立 的 对 象 型 数据 ， 它 们 可 被 单独 操 
作 ， 尤 其 是 status 对 象 ， 是 由 Kubernetes 系 统 单独 进行 自动 更 新 ， 而 不 能 
由 用 户 手动 操作 它 。 








3.2.1 资源 配置 清单 


3.1 节 中 曾 使 用 curl 命 令 通过 代理 的 方式 于 API Server 上 请 求 到 了 
kube-system 这 个 Namespace 活 动 对 象 的 状态 信息 ， 事 实 上 ， 用 户 也 可 以 
直接 使 用 “kubect] get TYPE/NAME-o yam 了 ”命令 获取 任何 一 个 对 象 的 
YAML 格 式 的 配置 清单 ， 或 者 使 用 “kubectl get TYPE/NAME-o json” 命 令 
~ 的 配置 清单 。 例 如 ， 可 使 用 下 面 的 命令 获取 kube-system 





~]$ kubectl1 get namespace kube-system -0 yaml 
apiVersion: v1 
kind: Namespace 
metadata: 
creationTimestamp: 2018-08-11T02:33:23Z 
name: kube-system 
resourceVersion: "33" 
selfLink: /api/vi/namespaces/kube-system 
uid: eb6bf659-9d0e-11e8-bfOd-000c29abof5b 
spec: 
finalizers: 
- kubernetes 
status: 
phase: Active 





除了 极 少 数 的 资源 之 外 ，Kubernetes 系 统 上 的 绝 大 多 数 资源 都 是 由 
其 使 用 者 所 创建 的 。 创 建 时 ， 需 要 以 与 上 述 输出 结果 中 类 似 的 方式 以 
YAML 或 JSON 序 列 化 方案 定义 资源 的 相关 配置 数据 ， 即 用 户 期 望 的 目 
标 状态 ， 而 后 再 由 Kubernetes 的 底层 组 件 确 保 活动 对 象 的 运行 时 状态 与 
用 户 提 供 的 配置 清单 中 定义 的 状态 无 限 接 近 。 因 此 ， 资 源 的 创建 要 通过 
用 户 提 供 的 资源 配置 清单 来 进行 ， 其 格式 类 似 于 kubectl get 命 令 获 取 到 
的 YAML 或 JSON 形 式 的 输出 结果 。 不 过 ，status 字 段 对 用 户 来 说 为 只 读 
字段 ， 它 由 Kubernetes 集 群 自 动 维护 。 例 如 ， 下 面 就 是 一 个 创建 
Namespace 资 源 时 提供 的 资源 配置 清单 示例 ， 它 仅 提 供 了 几 个 必要 的 字 


段 : 











apiVersion: v1 
kind: Namespace 
metadata: 

name: dev 
spec: 

finalizers: 

- kubernetes 


将 如 上 所 述 配置 清单 中 的 内 容 保 存 于 文件 中 ， 使 用 “kubectl create- 
f/PATH/TO/FILE” 命 令 即 可 将 其 创建 到 集群 中 。 创 建 完成 后 查看 其 
YAML 或 JSON 格 式 的 输出 结果 ， 可 以 看 到 Kubemetes 会 补 全 其 大 部 分 的 
字段 ， 并 提供 相应 的 数据 。 事 实 上 ，Kubernetes 的 大 多 数 资 源 都 能 够 以 
类 似 的 方式 进行 创建 和 查看 ， 而 且 它 们 几乎 都 遵循 类 似 的 组 织 结构 ， 下 
面 的 命令 显示 了 第 2 章 中 使 用 kubectl run 命 令 创建 的 Deployment 资 源 对 象 
myapp 的 状态 信息 : 








~]$ kubectl get deployment myapp -0 yaml 
apiVersion: extensions/vibetal 
kind: Deployment 
metadata: 
name: myapp 
spec: 
replicas: 3 
selector: 
matchLabels: 
run: myapp 








为 了 节约 篇 幅 ， 上 面 的 输出 结果 省 去 了 大 部 分 内 容 ， 仅 保留 了 其 主 
体 结 构 。 从 命令 结果 可 以 看 出 ， 它 也 遵循 Kubernetes API 标 准 的 资源 组 
织 格式 ， 由 apiVersion、kind、metadata、spec 和 status 五 个 核心 字段 组 
成 ， 只 是 spec 字 上 段 中 骸 套 的 内 容 与 Namespace 资 源 几 平 完 全 不 同 。 


事实 上 ， 对 几乎 所 有 的 资源 来 说 ，apiVersion、kind 和 metadata 字 段 
的 功能 基本 上 都 是 相同 的 ， 但 spec 则 用 于 资源 的 期 望 状态 ， 而 资源 之 所 
以 存在 类 型 上 的 不 同 ， 也 在 于 它们 的 棋 套 属性 存在 显著 差别 ， 它 由 用 户 
定义 和 维护 。 而 status 字 段 则 用 于 记录 活动 对 象 的 当前 状态 ， 它 要 与 用 
户 在 spec 中 定义 的 期 望 态 相同 ， 或 者 正 处 于 转换 为 与 其 相同 的 过 各 











3.2.2 ”metadata 扒 套 字 段 


metadata 字 上 段 用 于 描述 对 象 的 属性 信息 ， 其 内 骨 多 个 字段 用 于 定义 
资源 的 元 数据 ， 例 如 name 和 1labels 等 ， 这 些 字 段 大 体 可 分 为 必要 字段 和 
可 选 字段 两 大 类 。 名 称 空 间 级 别 的 资源 的 必 选 字段 包括 如 下 三 项 。 


namespace: 指定 当前 对 象 隶 属 的 名 称 空间 ， 默 认 值 为 default。 


name: 设 定 当前 对 象 的 名 称 ， 在 其 所 属 的 名 称 空间 的 同一 类 型 中 
必须 唯一 。 

-uid: 当前 对 象 的 唯一 标识 符 ， 其 唯一 性 仅 发 生 在 特定 的 时 间 段 和 
名 称 空间 中 ; 此 标识 符 主要 是 用 于 区 别 拥有 同样 名 字 的 “已 删 除 * 和 “ 重 
新 创建 ”的 同一 个 名 称 的 对 象 。 


可 选 字段 通常 是 指 由 Kubernetes 系 统 自 行 维 护 和 设置 ， 或 者 存在 默 
认 ， 或 者 本 和 刁 允 许 使 用 空 值 等 类 型 的 字段 ， 常 用 的 有 如 下 几 个 : 


labels: 设 定 用 于 标识 当前 对 象 的 标签 ， 键 值 数据 ， 第 被 用 作 挑 选 








条 件 


非 标 识 型 键 什 数据， 用 来 作为 挑选 条 件 ， 用 于 labels 
义 补 充 。 


:resourceVersion: 当前 对 象 的 内 部 版 本 标识 符 ， 用 于 让 客户 端 确定 
对 象 变动 与 否 。 


“generation: 用 于 标识 当前 对 象 目标 状态 的 代 别 。 

creationTimestamp: 当前 对 象 创 建 日 期 的 时 间 玲 。 

deletionTimestamp: 当前 对 象 删除 日 期 的 时 间 惟 。 

此 外 ， 用 户 通 过 配置 清单 创建 资源 时 ， 通 常 仅 需要 给 出 必 选 字段 ， 
可 选 字 段 可 按 需 指定 ， 对 于 用 户 未 明确 定义 的 租 套 字段 ， 则 需要 由 一 系 


列 的 finalizer 组 件 自动 予以 填充 。 而 用 户 需 要 对 资源 创建 的 目标 资源 对 
象 进行 强制 校 验 ， 或 者 在 修改 时 需要 用 到 initializer 组 件 完成 ， 例 如 ， 为 














每 个 待 创建 的 Pod 对 象 添加 一 个 Sidecar 容 器 等 。 不 同 的 资源 类 型 也 会 存 
在 一 些 专 有 的 骸 套 字段 ， 例 如 ，ConfigMap 资 源 还 支持 使 用 clusterName 
等 


3.2.3 ”spec 和 status 字 段 





Kubernetes 用 spec 来 描述 所 期 望 的 对 象 应 该 具有 的 状态 ， 而 用 status 
字段 来 记录 对 象 在 系统 上 的 当前 状态 ， 因 此 status 字 段 仅 对 活动 对 象 才 
有 意义 。 这 两 个 字段 都 属于 网 套 类 型 的 字段 。 在 定义 资源 配置 清单 时 ， 
spec 是 必须 定义 的 字段 ， 用 于 描述 对 象 的 目标 状态 ， 即 用 户 期 望 对 象 需 

| 出 来 的 特征 。status 字 上 段 则 记录 了 对 象 的 当前 状态 (或 实际 状 
， 此 字段 值 由 Kubernetes 系 统 负 责 填充 或 更 新 ， 用 户 不 能 手动 进行 
Master 的 controller-manager 通 过 相应 的 控制 占 组 件 动 态 管理 并 确 
保 对 象 的 实际 状态 匹配 用 户 所 期 望 的 状态 ， 它 是 一 种 调和 
(reconciliation〉 配置 系统 。 


例如 ，Deployment 是 一 种 用 于 朱 述 集群 中 运行 的 应 用 的 对 象 ， 央 
此 ， 创 建 Deployment 类 型 的 对 象 时 ， 需 要 为 目标 Deployment 对 象 设 定 
spec， 指 定期 望 需要 运行 的 Pod 副 本 数量 、 使 用 的 标签 选择 器 以 及 Pod 模 
板 等 。Kubernetes 系 统 读 取 待 创建 的 Deployment 对 象 的 spec 以 及 系统 上 
相应 的 活动 对 象 的 当前 状态 ， 必 要 时 进行 对 象 更 新 以 确保 status 字 段 吻 
合 spec 字 段 中 期 望 的 状态 。 如 果 这 其 中 任 一 实例 出 现 问 题 〈status 字 段 值 
发 生 了 变化 ) ， 那 么 Kubernetes 系 统 则 需要 及 时 对 spec 和 status 字 段 的 差 
异 做 出 啊 应 ， 例 如 ， 补 足 缺 失 的 Pod 副 本 数目 等 。 


spec 字 上段 检 套 的 字段 对 于 不 同 的 对 象 类 型 来 说 各 不 相同 ， 具 体 需 
参照 Kubernetes API 参 考 手 册 中 的 说 明 分 别 进行 获取 ， 核 ， J 
常用 配置 字段 将 会 在 本 书后 面 的 章节 中 进行 讲解 。 




















3.2.4 资源 配置 清单 格式 文档 


定义 资源 配置 清单 时 ， 尽 管 apiVersion、kind 和 metadata 有 章 可 循 ， 
但 spec 字 段 对 不 同 的 资源 来 说 却 是 千差万别 的 ， 因 此 用 户 需要 参考 
Kubernetes API 的 参考 文档 来 了 解 各 种 可 用 属性 字段 。 好 在 ，Kubernetes 
在 系统 上 内 建 了 相关 的 文档 ， 用 户 可 以 使 用 “kubectl explain” 命 令 直 接 获 
取 相 关 的 使 用 帮助 ， 它 将 根据 给 出 的 对 象 类 型 或 相应 的 藤 套 字段 来 显示 
相关 的 下 一 级 文档 。 例 如 ， 要 了 人 解 Pod 资 源 的 一 级 字段 ， 可 以 使 用 类 似 
如 下 的 命令 ， 命 令 结果 会 输出 支持 使 用 的 各 一 组 字段 及 其 说 明 : 




















~]$kubect1 explain pods 











需要 了 解 某 一 级 字段 表示 的 对 象 之 下 的 二 级 对 象 字段 时 ， 只 需要 指 
定 其 一 级 字段 的 对 象 名 称 即 可 ， 三 级 和 四 级 字段 对 象 等 的 查看 方式 依 此 
类 推 。 例 如 查看 Pod 资 源 的 Spec 对 象 支持 嵌 套 使 用 的 二 级 字段 ， 可 使 用 
类 似 如 下 的 命令 : 





~]$ kubectl1 explain pods.spec 
RESOURCE: spec <0bject> 


DESCRIPTION: 
Specification of the desired behavior of the pod,. ..... 


PodSpec is a description of a pod， 


FIELDS : 

activeDeadlineSeconds <integer> 
Optional duration in seconds the pod may be active on the node relative to 
StartTime before the System will actively try to mark it failed and kill 
associated containers，Value must be a positive integer. 

containers <[]0object> -required- 
List of containers belonging to the pod. Containers cannot currently be 
added or removed. There must be at least one container in a Pod. Cannot 

be updated. 





对 象 的 spec 字 有 段 的 文档 通常 包含 RESOURCE、DESCRIPTION 和 
FIELDS 几 节 ， 其 中 FIELDS 节 中 给 出 了 可 花 套 使 用 的 字段 、 数 据 类 型 及 
功能 描述 。 例 如 ， 上 面 命令 的 结果 显示 在 FIELDS 中 的 containers 字 上段 的 
数据 类 型 是 一 个 对 象 列表 ([]Object) ， 而 且 是 一 个 必 选 字 段 。 任 何 值 


为 对 象 类 型 数据 的 字段 都 会 嵌 套 一 到 多 个 下 一 级 字段 ， 例 如 ，Pod 对 象 
中 的 每 个 容 右 也 是 对 象 类 型 数据 ， 它 同样 包含 姐 僚 字段 ， 但 容 占 不 文 持 
单独 创建 ， 而 是 要 包含 于 Pod 对 象 的 上 下 文中 ， 其 详细 信息 可 通过 三 级 
字段 来 获取 ， 命 令 及 其 结果 示例 如 下 : 








~]$ kubect1 explain pods.spec.containers 
RESOURCE: containers <[]0object> 


DESCRIPTION: 
List of containers belonging to the pod. Containers cannot currently be added 
or removed. There must be at least one container in a Pod. Cannot be updated. 


A single application container that you want to run within a pod. 


FIELDS : 
args <[]string> 
Arguments to the entrypoint，The docker image's CMD is used if this is not 
provided, ..... 


command <[]string> 
Entrypoint array. Not executed within a shell. The docker image's 
ENTRYPOINT is used if this Is not provided. ..... 


env <[]object> 
List of environment variables to set in the container. Cannot be updated. 





内 建文 档 大 大 降低 了 用 户 手 动 创建 资源 配置 清单 的 难度 ， 尝 试 使 用 
某 个 资源 类 型 时 ，explain 也 的 确 是 用 户 的 常用 命令 之 一 。 熟 悉 各 常用 字 
段 的 功用 之 后 ， 以 同类 型 的 现 有 活动 对 象 的 清单 为 模板 可 以 更 快 地 生成 
目标 资源 的 配置 文件 ， 命 令 格式 为 “kubectl get TYPE NAME-o yaml-- 
export"， 其 中 --export 选 项 用 于 省 略 输出 由 系统 生成 的 信息 。 例 如 ， 基 
于 现在 的 Deployment 资 源 对 象 myapp 生 成 配置 模板 deploy-demo.yaml 文 
件 ， 可 以 使 用 如 下 命令 : 





~]$ kubectl get deployment myapp -0 yaml --export > deploy-demo.yaml 








通过 资源 清单 文件 管理 资源 对 象 较 之 直接 遂 过 命令 行进 行 操作 有 着 
诸多 优势 ， 具 体 包括 命令 行 的 操作 方式 仅 文 持 部 分 资源 对 象 的 部 分 属 
性 ， 而 资源 清单 文 持 配 置 资源 的 所 有 属性 字段 ， 而 且 使 用 配置 清单 文件 
还 能 够 进行 版 本 奶 踩 、 复 审 等 高 级 功能 的 操作 。 本 书后 续 章 节 中 的 大 部 
分 资源 管理 操作 都 会 借助 于 资源 配置 文件 进行 。 




















3.2.5 ”资源 对 象 管理 方式 


Kubernetes 的 API Server 遵 循 声明 式 编程 〈( declarative programming ) 
范式 而 设计 ， 侧 重 于 构建 程序 程序 逻辑 而 无 须 用 户 描 述 其 实现 流程 ， 用 
户 只 需要 设 定期 望 的 状态 ， 系 统 即 能 自行 确定 需要 执行 的 操作 以 确保 达 
到 用 户 期 望 的 状态 。 人 例如， 期望 某 Deployment 控 制 器 管理 三 个 Pod 资 源 
对 象 时 ， 而 系统 观察 到 的 当前 数量 却 是 两 个 ， 于 是 系统 就 会 知道 需要 创 

建 一 个 新 的 Pod 资 源 来 满足 此 期 望 。Kubernetes 的 自 愈 、 自 治 等 功能 都 依 
赖 于 其 声明 式 机 制 。 


与 此 对 应 的 另 一 种 范式 称 为 陈述 式 编 程 〈imperative 

programming) ， 代 码 侧重 于 通过 创建 一 种 告诉 计算 机 如 何 执 行 操作 的 

算法 来 更 改 程序 状态 的 语句 来 完成 ， 它 与 硬件 的 工作 方式 密切 相关 ， 通 
常 ， 代 码 将 使 用 条 件 语句 、 循 环 和 类 继承 等 控制 结构 。 为 了 便于 用 户 使 
用 ，Kubernetes 的 API Server 也 文 持 陈述 式 范式 ， 它 直接 通过 命令 及 其 选 
项 完成 对 象 的 管理 操作 ， 前 面 用 到 的 run、expose、delete 和 get 等 命令 都 
属于 此 类 ， 执 行 时 用 户 需 要 告诉 系统 要 做 什么 ， 例 如 ， 使 用 run 命 令 创 

建 一 个 有 着 3 个 Pod 对 象 副 本 的 Deployment 对 象 ， 或 者 通过 delete 命 令 删 

除 一 个 名 为 myapp 的 Service 对 象 。 


Kubernetes 系 统 的 大 部 分 API 对 象 都 有 着 spec 和 和 status 两 个 字段 ， 其 
中 ，spec 用 于 让 用 户 定义 所 期 望 的 状态 ， 系 统 从 中 读 出 相关 的 定义 ; 而 
status 则 是 系统 观察 并 负责 写 入 的 当前 状态 ， 用 户 可 以 从 中 获取 相关 的 
信息 。Kubernetes 系 统 通过 控制 器 监控 着 系统 对 象 ， 由 其 负责 让 系统 当 
前 的 状态 无 限 接 近 用 户 所 期 望 的 状态 。 


kubectl 的 命令 由 此 可 以 分 为 三 类 : 陈述 式 命令 (imperative 
command) 、 陈 述 式 对 象 配置 (imperative object configuration ) 和 声明 
式 对 象 配置 (declarative object configuration) 。 第 一 种 方式 即 此 前 用 到 
的 run、expose、delete 和 get 等 命令 ， 它 们 直接 作用 于 Kubernetes 系 统 上 
的 活动 对 象 ， 简 单 易 用 ， 但 不 支持 代码 复 用 、 修 改 复审 及 审计 日 志 等 功 
能 ， 这 些 功 能 的 使 用 通常 要 依赖 于 资源 配置 文件 ， 这 些 文 件 也 称 为 资源 
清单 。 在 这 种 模式 下 ， 用 户 可 以 访问 每 个 对 象 的 完整 模式 ， 但 用 户 还 需 
要 深入 学 习 Kubernetes API。 


如 3.2.4 节 所 述 ， 资 源 清单 本 质 上 是 一 个 JSON 或 YAML 格 式 的 文本 











文件 ， 由 资源 对 象 的 配置 信息 组 成 ， 文 持 使 用 Git 等 进行 版 本 控制 。 而 
用 户 可 以 资源 清单 为 基础 ， 在 Kubernetes 系 统 上 以 陈述 式 或 声明 式 进 行 
资源 对 象 管理 ， 如 图 3-4 所 示 。 


' resources kind Kubernetes Cluster 
EEES Deployment 轿 E 


lapis/<group>/<version>/ | 


h ] 
Uists PodList | 
kubectl - 轩 : NamespaceList 电 


JSGNI | gp 
1 special 


\ :| /status el 
http/https | | 


图 3-4 ”基于 资源 配置 清单 管理 对 象 


陈述 式 管理 方式 包括 create、delete、get 和 replace 等 命令 ， 与 陈述 式 
命令 的 不 同 之 处 在 于 ， 它 通过 资源 配置 清单 谈 取 需要 管理 的 目标 资源 对 
象 。 陈 述 式 对 象 配置 的 管理 操作 直接 作用 于 活动 对 象 ， 即 便 仅 修改 配置 
清单 中 的 极 小 一 部 分 内 容 ， 使 用 replace 命 令 进行 的 对 象 更 新 也 将 会 导致 
整个 对 象 被 蔡 换 。 进 一 步 地 ， 混 合 使 用 陈述 式 命令 进行 清单 文件 币 外 修 
改 时 ， 必 然 会 导致 用 户 丢 失 活动 对 象 的 当前 状态 。 


声明 式 对 象 配置 并 不 直接 指明 要 进行 的 对 象 管理 操作 ， 而 是 提供 配 
置 清 单 文 件 给 Kubernetes 系 统 ， 并 委托 系统 跟踪 活动 对 象 的 状态 变动 。 
资源 对 象 的 创建 、 删 除 及 修改 操作 全 部 通过 唯一 的 命令 apply 来 完成 ， 
并 且 每 次 操作 时 ， 提 供给 命令 的 配置 信息 都 将 保存 于 对 象 的 注解 信息 

(kubectl.kubernetes.io/last-applied-configuration〉 中 ， 并 通过 对 比 检查 
活动 对 象 的 当前 状态 、 注 解 中 的 配置 信息 及 资源 清单 中 的 配置 信息 三 方 
进行 变更 合并 ， 从 而 实现 仅 修 改变 动 字段 的 高 级 补丁 机 制 。 


陈述 式 对 象 配置 相 较 于 声明 式 对 象 配置 来 说 ， 其 缺点 在 于 同一 目录 
下 的 配置 文件 必须 同时 进行 同一 种 操作 ， 例 如 ， 要 么 都 创建 ， 要 么 部 更 









































新 等 ， 而 且 其 他 用 户 的 更 新 也 必须 反映 在 配置 文件 中 ， 不 然 其 更 新 在 一 
下 次 的 更 新 中 将 会 被 履 盖 。 因 此 ， 声 明 式 对 象 配 置 是 优先 推荐 给 用 户 使 
用 的 管理 机 制 |。 


然而 ， 对 于 新 手 来 说 ， 陈 述 式 命令 的 配置 方式 最 易于 上 手 ， 对 系统 
有 所 了 解 后 易于 切换 为 使 用 陈述 式 对 象 配置 管理 方式 。 因 此 ， 知 推荐 给 
高 级 用 户 则 推荐 使 用 声明 式 配置 ， 并 建议 同时 使 用 版 本 控制 系统 存储 所 
期 望 的 状态 ， 以 及 跨 对 象 的 历史 信息 ， 并 局 用 变更 复审 机 制 。 另 外 ， 推 
荐 使 用 借助 于 kube-applier 等 一 类 的 项 目 实现 目 动 化 声明 式 配 置 ， 用 户 将 
配置 推送 到 Git 仓 库 中 ， 然 后 借助 此 类 工具 即 能 将 其 自动 同步 于 
Kubernetes 集 群 上 。 











3.3 ”kubectl 命 令 与 资源 管理 


API Server 是 Kubernetes 集 群 的 网 关 ， 用 户 和 管理 员 以 及 其 他 客户 端 
仅 能 通过 此 网 关 接 口 与 集群 进行 交互 。API 是 面向 程序 员 的 访问 接口 ， 
目前 可 较 好 地 支持 Golang 和 和 Python 编程 语 言 ， 当 然 ， 终 端 用 户 更 为 常用 
的 是 通用 命令 行 工具 kubectl。 访 问 集群 之 前 ， 各 类 客户 端 需要 了 解 集群 
的 位 置 并 拥有 访问 集群 的 凭据 才能 获取 访问 许可 。 使 用 kubeadm 进 行 集 
群 初始 化 时 ，kubeadm init 上 自动 生成 的 /etckubernetes/admin.conf 文 件 是 客 
户 端 接 入 当前 集群 时 使 用 的 kubeconfig 文 件 ， 它 内 建 了 用 于 访问 
Kubernetes 集 群 的 最 高 管理 权限 的 用 户 账号 及 相关 的 认证 凭据， 可 由 
kubect 直接 使 用 。 








3.3.1 资源 管理 操作 概述 


资源 的 管理 操作 可 简单 归结 为 增 、 删 、 改 、 查 四 种 ，kubectl 提 供 了 
一 系列 的 子 命令 用 于 执行 此 类 任务 ， 如 create、delete、patch、apply、 
replace、edit、get 等 ， 其 中 有 些 命令 必须 基于 资源 清单 来 进行 ， 如 apply 
和 replace 命 令 ， 也 有 些 命令 既 可 基于 清单 文件 进行 ， 也 可 实时 作用 于 活 
动 资 源 之 上 ， 如 create、get、patch 和 delete 等 。 


kubectl 命 令 能 够 读 取 任何 以 .yaml、.yml 或 .json 为 后 级 的 文件 (可 称 
为 配置 清单 或 配置 义 件 ， 后 文 将 不 加 区 别 地 使 用 这 两 个 术语 )。 实 践 
中 ， 用 户 既 可 以 为 每 个 资源 使 用 专用 的 清单 文件 ， 也 可 以 将 多 个 相关 的 
资源 《例如 ， 属 于 同一 个 应 用 或 微服 务 ) 组 织 在 同一 个 清单 文件 中 。 不 
过 ， 如 果 是 YAML 格 式 的 清单 文件 ， 多 个 资源 役 此 之 间 要 使 用 “---” 符 号 
作为 单独 的 一 行进 行 资 源 分 割 。 这 样 ， 多 个 资源 就 将 以 清单 文件 中 定义 
的 次 序 被 create、apply 等 子 命令 调用 。 


kubectl 的 多 数 子 命令 支持 使 用 “-f* 选 项 指定 使 用 的 清单 文件 路 径 或 
URL， 也 可 以 是 存储 有 清单 文件 的 目录 ， 另 外 ， 此 选项 在 同一 命令 中 也 
可 重复 使 用 多 次 。 如 果 指 定 的 目录 路 径 存 在 子 目 录 中 时 ， 那 么 可 按 需 同 
时 使 用 “-R? 选 项 以 递归 获取 子 目 录 中 的 配置 清单 。 


再 者 ， 支 持 使 用 标签 和 注解 是 Kubernetes 系 统 的 一 大 特色 ， 它 为 资 
源 管 理 机 制 增色 不 少 ， 而 且 delete 和 get 等 命令 能 够 基于 标签 挑选 目标 对 
象 ， 有 些 资源 甚至 必须 依赖 于 标签 才能 正常 使 用 和 工作 ， 例 如 Service 和 
Pod 控 制 占 Deployment 等 资源 对 象 。 子 命令 label 用 于 管理 资源 标签 ， 而 
管理 资源 注解 的 子 命令 则 是 annotate。 


就 地 更 新 《修改 ) 现 有 的 资源 也 是 一 种 常见 的 操作 。apply 命 令 通 
过 比较 资源 在 清早 文件 中 的 版 本 及 前 一 次 的 版 本 执行 更 新 操作 ， 它 不 会 
对 未 定义 的 属性 产生 额外 的 作用 。edit 命 令 相 当 于 先 使 用 get 命 令 获 取 资 
源 配置 ， 通 过 交互 式 编辑 器 修改 后 再 自动 使 用 apply 命 令 将 其 应 用 。 
patch 命 令 基 于 JSON 补 丁 、JSON 合 并 补丁 及 策略 合并 补丁 对 资源 进行 就 
地 更 新 操作 。 














名 提示 “为 了 利用 apply 命 令 的 优势 ， 用 户 应 该 总 是 使 用 apply 命 


邻 或 create--save-config 命 令 创建 资源 。 


3.3.2 ”kubectl 的 基本 用 法 


kubectl 是 最 常用 的 客户 并 工具 之 一 ， 它 提供 了 基于 命令 行 访问 
Kubernetes API 的 简洁 方式 ， 能 够 满足 对 Kubernetes 的 绝 大 部 分 的 操作 需 
求 。 例 如 ， 需 要 创建 资源 对 象 时 ，kubectl 会 将 JSON 格 式 的 清单 内 容 以 
POST 方式 提交 至 API Server。 本 节 主 要 描述 kubectl 的 基本 功能 。 





名 提示 “如果 要 单独 部 署 kubectt，Kubernetes 也 提供 了 相应 的 单 
独 发 行 包 ， 或 者 适 配 于 各 平台 的 程序 管理 颖 的 相关 程序 包 ， 如 rpm 包 或 
deb 包 等 ， 用 户 根据 平台 类 型 的 不 同 获 取 相 匹配 的 版 本 安装 完成 即 可 ， 
操作 步骤 类 似 于 前 面 的 安装 方法 ， 因 此 这 里 不 再 给 出 其 具体 过 程 。 


kubectl 是 Kubernetes 系 统 的 命令 行 客 户 端 工 具 ， 特 性 丰 宇 且 功 能 强 
大 ， 是 Kubernetes 管 理 员 最 常用 的 集群 管理 工具 。 其 最 基本 的 语法 格式 
为 “kubectl[commandj[TYPE]INAME][flagsj”， 其 中 各 部 分 的 简要 说 明 如 
下 


1) command: 对 资源 执行 相应 操作 的 子 命令 ， 如 get、create、 
delete、run 等 ; 第 用 的 核心 子 命令 如 表 3-1 所 示 。 


2) TYPE: 要 操作 的 资源 对 象 的 类 型 ， 如 pods、services 等 ， 类 型 名 
称 区 分 字符 大 小 写 ， 但 文 持 使 用 简写 格式 。 


3) NAME: 对 象 名 称 ， 区 分 字符 大 小 写 ; 省 略 时 ， 则 表示 指定 
TYPE 的 所 有 资源 对 象 ， 另 外 ， 也 可 以 直接 使 用 “TYPE/NAME” 的 格式 来 
表示 资源 对 象 。 


4) flags: 命令 行 选 项 ， 如 “-s” 或 “--server”;， 另外 ，get 等 命令 在 输 
出 时 还 有 一 个 常用 的 标志 “-o<format>” 用 于 指定 输出 格式 ， 如 表 3-1 所 
人 外 o 





表 3-1 ”kubectl 的 子 命令 列表 


命令 | 命 类 别 | 


create 
expose 
基础 命令 (初级 ) 
un 
set 


get 
explain 
. 基础 命令 (中级) 
edit 
delete 


rollout 
rolling-update 
部 署 命令 
Scale 
antoscale 


certificate 
cluster-info 


top 

cordon 集群 管理 命令 
uncordon 

drain 

taint 


describe 

logs 

attach 

-一 排 错 及 调试 命令 
port-forward 

Pproxy 

cp 

auth 





功能 说 阴 
通过 文件 或 标准 输入 创建 资源 
基于 rc 、service 、deployment 或 pod 创建 Service 资源 
通过 创建 Deployment 在 集群 中 运行 指定 的 镜像 
设置 指定 资源 的 特定 属性 
显示 一 个 或 多 个 资源 
打印 资源 文档 
编辑 资源 
基于 文件 名 、stdin、 资 源 或 名 字 ， 以 及 资源 和 选择 器 删除 资源 
管理 资源 的 滚动 更 新 
对 ReplicationController 执行 滚动 升级 
伸缩 Deployment、ReplicaSet、RC 或 Job 的 规模 
对 Deployment、ReplicaSet 或 RC 进行 自动 伸缩 
配置 数字 证 书 资源 
打印 集群 信息 
打印 资源 (CPU/Memory/Storage) 使 用 率 
将 指定 node 设 定 为 “不 可 用 ” (unschedulable) 状态 
将 指定 node 设 定 为 “可 用 ” (schedulable) 状态 
“ 排 干 ”指定 的 node 的 负载 以 进入 “维护 ”模式 
为 node 声明 污点 及 标准 行为 
显示 指定 的 资源 或 资源 组 的 详细 信息 
显示 一 个 Pod 内 某 容 器 的 日 志 
附加 终端 至 一 个 运行 中 的 容器 
在 容器 中 执行 指定 命令 
将 本 地 的 一 个 或 多 个 端口 转发 至 指定 的 Pod 
创建 能 够 访问 Kubernetes API Server 的 代理 
在 容器 间 复 制 文件 或 目录 
打印 授权 信息 


命令 功能 说 明 


apply 基于 文件 或 stdin 将 配置 应 用 于 资源 

> 高 级 命令 使 用 策略 合并 补丁 更 新 资源 字段 

replace 基于 文件 或 stdin 替换 一 个 资源 

convert 为 不 同 的 API 版 本 转换 配置 文件 

label 更 新 指定 资源 的 label 

annotate 更 新 资源 的 annotation| 

completion 输出 指定 的 shell (如 bash) 的 补 全 码 
version 打印 Kubernetes 服务 端 和 客户 端的 版 本 信息 


以 “group/version ”格式 打印 服务 器 支持 的 API 版 本 信息 
config 命令 配置 kubeconfig 文件 的 内 容 


apli-versions 





plugin 运行 命令 行 插件 
help 打印 任 一 命令 的 帮助 信息 


kubectl 命 令 还 包含 了 多 种 不 同 的 输出 格式 《如 表 3-2 所 示 ) ， 它 们 
为 用 户 提 供 了 非常 灵活 的 自 定 义 输 出 机 制 ， 如 输出 为 YAML 或 JSON 格 


TO 


表 3-2 ”kubectl get 命 令 的 常用 输出 格式 


输出 格式 格式 说 明 
-0 wide 显示 资源 的 额外 信息 
-0 name 仅 打印 资源 的 名 称 
-0 yaml YAML 格式 化 输出 API 对 象 信息 
-0 json JSON 格式 化 输出 API 对 象 信息 
-0 go-template 以 自 定 义 的 go 模板 格式 化 输出 API 对 象 信息 
-0 custom-columns 自 定义 要 输出 的 字段 


此 外 ，kubectl 命 令 还 有 许多 通用 的 选项 ， 这 个 可 以 使 用 “kubectl 
options” 命 令 来 获取 。 下 面 列举 几 个 比较 常用 命令 。 


-Ss 或 --server: 指定 API Server 的 地 址 和 端口 。 


.--kubeconfig: 使 用 的 kubeconfig 文 件 路 径 ， 默 认为 ~/.kube/config。 





--namespace: 命令 执行 的 目标 名 称 空 间 。 


kubect 的 部 分 子 命令 在 第 2 章 已 经 多 次 提 到 ， 余 下 的 大 多 数 命 令 在 





人 的 章节 中 还 会 用 到 ， 对 于 筷 们 的 使 用 说 明 也 将 在 首次 用 到 时 进行 展 
开 说 明 。 


3.4 管理 名 称 空间 资源 


名 称 空间 (Namespace) 是 Kubernetes 集 群 级 别 的 资源 ， 用 于 将 集群 
分 隔 为 多 个 隔离 的 逻辑 分 区 以 配置 给 不 同 的 用 户 、 租 户 、 环 境 或 项 目 使 
用 ， 例如， 可 以 为 development、gqa 和 production 应 用 环境 分 别 创 建 各 上 自 
的 名 称 空间 。 


Kubernetes 的 绝 大 多 数 资 源 都 隶属 于 名 称 空间 级 别 〈 另 一 个 是 全 局 
级 别 或 集群 级 别 ) ， 名 称 空间 资源 为 这 类 的 资源 名 称 提 供 了 隔离 的 作用 
域 ， 同 一 名 称 空间 内 的 同一 类 型 资源 名 必须 是 唯一 的 ， 但 跨 名 称 空间 时 
并 无 此 限制 。 不 过 ，Kubernetes 还 是 有 一 些 资源 隶属 于 集群 级 别 的 ， 如 
Node、Namespace 和 PersistentVolume 等 资源 ， 它 们 不 属于 任何 名 称 空 
间 ， 因 此 资源 对 象 的 名 称 必须 全 局 唯一 。 














O 注意 ”Kubernetes 的 名 称 空间 资源 不 同 于 Linux 系 统 的 名 称 空 
间 ， 它 们 是 各 自 独 立 的 概念 。 另 外 ，Kubernetes 名 称 空间 并 不 能 实现 Pod 
间 的 通信 隔离 ， 它 仅 用 于 限制 资源 对 象 名 称 的 作用 域 。 





3.4.1 查看 名 称 空间 及 其 资源 对 象 


Kubernetes 集 群 默认 提供 了 几 个 名 称 空 间 用 于 特定 的 目的 ， 例 如 ， 
kube-system 主 要 用 于 运行 系统 级 资源 ， 而 default 则 为 那些 未 指定 名 称 空 
间 的 资源 操作 提供 一 个 默认 值 ， 前 面 章节 中 的 绝 大 多 数 资源 管理 操作 都 
在 default 名 称 空间 中 进行 。“kubectl get namespaces” 命 令 则 可 以 查看 
namespaces 资 源 : 














~]$ kubectl1 get namespaces 
NAME STATUS AGE 
default Active 6d 
kube-public Active 6d 
kube-system Active 6d 








也 可 以 使 用 “kubectl describe namespaces” 命 令 查 看 特定 名 称 空间 的 
详细 信息 ， 例 如 : 





~]$ kubectl1 describe namespaces default 








kubectl 的 资源 查看 命令 在 多 数 情况 下 应 该 针对 特定 的 名 称 空间 来 进 
行 ， 为 其 使 用 “-n” 或 “--namespace” 选 项 即 可 ， 例 如， 查看 kube-system 下 
的 所 有 Pod 资 源 : 








~]$ kubectl1 get pods -n kube-system 


NAME READY STATUS RESTARTS AGE 
etcd-master.ikubernetes.io 1/1 Running 1 6d 
kube-apiserver-master.ikubernetes.io 1/1 Running 1 6d 





命令 结果 显示 出 kube-system 与 default 名 称 空间 的 Pod 资 源 对 象 并 不 
相同 ， 这 正 是 Namespace 资 源 的 名 称 隔离 功能 的 体现 。 有 了 Namespace 
对 象 ， 用 户 再 也 不 必 精 心安 排 资 源 名 称 ， 也 不 用 担心 误 操作 了 其 他 用 户 
的 资源 。 


3.4.2 ”管理 Namespace 资 源 


Namespace 是 Kubernetes API 的 标准 资源 类 型 之 一 ， 如 3.2.1 节 中 所 
述 ， 它 的 配置 主要 有 kind、apiVersion、metadata 和 spec 等 一 级 字段 组 
成 。 将 3.2.1 节 中 的 名 称 空间 配置 清单 保存 于 配置 文件 中 ， 使 用 陈述 式 对 
象 配置 命令 create 或 声明 式 对 象 配置 命令 apply 便 能 完成 创建 : 





~]$ kubect1l apply -f namespace-example.yaml 
namespace/dev created 








名 称 空 间 资 源 属 性 较 少 〈 通 党 只 需要 指定 名 称 即 可 ) ， 简 单 起 见 ， 
kubectl 为 其 提供 了 一 个 封闭 的 专用 陈述 式 命 令 “kubectl create 
namespace”。Namespace 资 源 的 名 称 仅 能 由 字母 、 数 字 、 连 接线 、 下 划 
例如 ， 下 面 的 命令 可 用 于 创建 名 为 qa 的 Namespace 对 





~]$ kubectl1 create namespace qa 
namespace/qa created 





O 注意 namespace 资源 的 名 称 仅 能 由 字母 、 数 字 、 连 接线 、 下 
划 线 等 字符 组 成 。 


实践 中 ， 不 建议 混用 不 同类 别 的 管理 方式 。 考 虑 到 声明 式 对 象 配置 
管理 机 制 的 强大 功能 ， 强 烈 推 荐 用 户 使 用 apply 和 patch 等 合 令 进行 资源 
创建 及 修改 一 类 的 管理 操作 。 

使 用 kubectl 窒 理 资 源 时 ， 如 果 一 并 提供 了 名 称 空间 选项 ， 就 表示 此 
管理 操作 仅 针 对 指定 名 称 空间 进行 ， 而 删除 Namespace 资 源 会 级 联 删 除 
其 包含 的 所 有 其 他 资源 对 象 。 表 3-3 给 出 了 几 个 常用 的 命令 格式 。 


表 3-3 ”结合 名 称 空间 使 用 的 删除 命令 





命令 格式 功能 


kubectl delete TYPE RESOURCE -n NS 删除 指定 名 称 空间 内 的 指定 资源 
kubectl delete TYPE --all -n NS 删除 指定 名 称 空间 内 的 指定 类 型 的 所 有 资源 
kubectl delete all -n NS 删除 指定 名 称 空间 内 的 所 有 资源 
kubectl delete all --all 删除 所 有 名 称 空间 中 的 所 有 资源 


需要 再 次 指出 的 是 ，Namespace 对 象 仅 用 于 资源 对 象 名 称 的 隔离 ， 
它 自身 并 不 能 隔绝 跨 名 称 空间 的 Pod 间 通信 ， 那 是 网 络 策略 (network 
policy) 资源 的 功能 。 


3.5 “Pod 资 源 的 基础 管理 操作 


Pod 是 Kubernetes API 中 的 核心 资源 类 型 ， 它 可 以 定义 在 JSON 或 
YAML 格 式 的 资源 清单 中 ， 由 资源 管理 命令 进行 陈述 式 或 声明 式 管 理 。 
创建 时 ， 用 户 通 过 create 或 apply 命 令 将 请 求 提交 到 API Server 并 将 其 保存 
至 集群 状态 存储 系统 etcd 中 ， 而 后 由 调度 器 将 其 调度 至 最 佳 目标 节点 ， 
并 被 相应 节点 的 kubelet 借 助 于 容器 引 敬 创建 并 启动 。 这 种 由 用 户 直 接 通 
过 API 创 建 的 Pod 对 象 也 称 为 自主 式 Pod。 








3.5.1 ”陈述 式 对 象 配 置 管理 方式 


陈述 式 对 象 配 置 管理 机 制 ， 是 由 用 户 通 过 配置 文件 指定 要 管理 的 目 
标 资 源 对 象 ， 而 后 再 由 用 户 借 助 于 命令 直接 指定 Kubernetes 系 统 要 执行 
的 管理 操作 的 管理 方式 ， 常 用 的 命令 有 create、delete、replace、get 利 
describe 等 。 





1. 创 建 Pod 资 源 


Pod 是 标准 的 Kubernetes API 资 源 ， 在 配置 清单 中 使 用 kind、 
apiVersion、metadata 和 spec 字 段 进 行 定 义 ，status 字 段 在 对 象 创建 后 由 系 
统 自行 维护 。Pod 对 象 的 核心 功用 在 于 运行 容器 化 应 用 ， 在 其 spec 字 段 
中 舱 套 的 必 选 字段 是 containers， 它 的 值 是 一 个 容器 对 象 列表 ， 文 持 舱 套 
创建 一 到 多 个 容器 。 下 面 是 一 个 Pod 资 源 清单 示例 文件 ， 在 spec 中 定义 
的 期 望 的 状态 是 在 Pod 对 象 中 基于 ikubernetes/myapp: v1 镜像 运行 一 个 名 
为 myapp 的 容器 : 








apiVersion: v1 
kind: Pod 
metadata: 

name: pod-example 
spec: 

containers: 

- name: myapp 

image: ikubernetes/myapp:vi1 





把 上 面 的 内 容 保 存 于 配置 文件 中 ， 使 用 “kubectl[COMMAND]- 
f/PATH/TO/YAML_FILE” 命 令 以 陈述 式 对 象 配 置 进 行 资源 对 象 的 创建 ， 
下 面 是 相应 的 命令 及 啊 应 结果 : 





~]$ kubectl create -f pod-example.yaml 
pod/pod-example created 





@ 如 果 读 者 熟悉 JSON， 也 可 以 直接 将 清单 文件 定义 为 
JSON 格 式 ; YAML 格 式 的 清单 文件 本 身 也 是 由 API Server 事 先 将 其 转换 
为 JSON 格 式 而 后 才 进 行 应 用 的 。 











命令 的 返回 信息 表示 目标 Pod 对 象 pod-example 得 以 成 功 创建 。 事 实 
上 ，create 命 令 中 的 -选项 也 文 持 使 用 目录 路 径 或 URL， 而 且 目 标 路 径 为 
目录 时 ， 还 支持 使 用 -R 选 项 进行 子 目录 递归 。 另 外 ，--record 选 项 可 以 
将 命令 本 号 记 录 为 目标 对 象 的 注解 信息 kubernetes.io/change-cause， 而 -- 
save-config 则 能 够 将 提供 给 命令 的 资源 对 象 配置 信息 保存 于 对 象 的 注解 
信息 kubectl.kubernetes.io/last-applied-configuration 中 ， 后 一 个 命令 的 功 
用 与 声明 式 对 象 配 置 命令 apply 的 功能 相近 。 


2. 查 看 Pod 状 态 


get 命 令 默 认 显 示 资 源 对 象 最 为 关键 的 状态 信息 ， 而 describe 等 命令 
则 能 够 打印 出 Kubernetes 资 源 对 象 的 详细 状态 。 不 过 ， 虽 然 创 建 时 给 出 
的 资源 清单 文件 较为 简洁 ， 但 “kubectl get” 命 令 既 可 以 使 用 “-o yaml” 或 “- 
o json2 选 项 输出 资源 对 象 的 配置 数据 及 状态 ， 也 能 够 借助 于 “--custom- 
columns” 选 项 上 自 定 义 要 显示 的 字段 : 











~]$ kubectl get -f pod-example.yaml 

NAME READY STATUS RESTARTS AGE 

pod-example 1/1 Running 0 1m 

~]$ kubectl1 get -f pod-example.yaml -0 custom-columns=NAME:metadata,namey STATUS:Stat 
NAME STATUS 

pod-example Running 





使 用 “-o yaml” 或 “-o json” 选 项 时 ，get 命 令 能 够 返回 资源 对 象 的 元 数 
据 、 期 望 的 状态 及 当前 状态 数据 信息 ， 而 要 打印 活动 对 象 的 详细 信息 ， 
则 需要 describe 命 令 ， 它 可 根据 资源 清单 、 资 源 名 或 卷 标 等 方式 过 滤 输 
出 符合 条 件 的 资源 对 象 的 信息 。 命 令 格式 为 “kubectl describe (-f 
FILENAMEITYPE[NAME_PREFIX|-1 label]|ITYPE/NAME) ”。 例 如 ， 显 
示 pod-example 的 详细 信息 ， 可 使 用 类 似 如 下 的 命令 : 











~]$ kubectl describe -f pod-example.yaml 





对 于 Pod 资 源 对 象 来 说 ， 它 能 够 返回 活动 对 象 的 元 数据 、 当 前 状 
态 、 容 器 列表 及 各 容器 的 详情 、 存 储 卷 对 象 列 表 、QoS 类 别 、 事 件 及 相 
天 信息 ， 这 些 详情 对 于 了 解 目 标 资源 对 象 的 状态 或 进行 错误 排查 等 操作 


3. 更 新 Pod 资 源 





对 于 活动 对 象 ， 并 非 其 每 个 属性 值 都 文 持 修改 ， 例 如 ，Pod 资 源 对 
象 的 metadata.name 字 段 就 不 文 持 修改 ， 除 非 删除 并 重建 它 。 对 于 那些 文 
持 修 改 的 属性 ， 比 如 ， 容 器 的 image 字 段 ， 可 将 其 完整 的 配置 清单 导出 
于 配置 文件 中 并 更 新 相应 的 配置 数据 ， 而 后 使 用 replace 命 令 基 于 陈述 式 
对 象 配置 的 管理 机 制 进 行 资 源 对 象 的 更 新 。 例 如 ， 将 前 面 创建 pod- 
example 时 使 用 的 资源 清单 中 的 image 值 修改 为 “ikubernetes/myapp: 

V2”， 而 后 执行 更 新 操作 : 








~]$ kubect1 get pods pod-example -o yaml > pod-example-update.yaml 

~]$ sed -i 's@\(image:\).*@ikubernetes/myapp:v2@' pod-example-update.yaml 
~]$ kubectl1 replace -f pod-example-update.yaml 

pod/pod-example replaced 





更 新 活动 对 象 的 配置 时 ，replace 命 令 要 重 构 整 个 资源 对 象 ， 故 此 它 
必须 基于 完整 格式 的 配置 信息 才能 进行 活动 对 象 的 完全 蔡 换 。 各 要 基于 
此 前 的 配置 文件 进行 将 换 ， 惑 必须 使 用 --force 选 项 删除 此 前 的 活动 对 
象 ， 而 后 再 进行 新 建 操作 ， 人 否则 命令 会 返回 错误 信息 。 例 如 ， 将 前 面 第 
一 步 “创建 Pod 资 源 ” 内 的 配置 清单 中 的 镜像 修改 为 “ikubernetes/myapPp: 
Vv2” 后 再 进行 强制 答 换 ， 命 令 如 下 : 





~]$ kubectl replace -f pod-example.yaml --force 
pod "pod-example" deleted 
pod/pod-example replaced 





4. 删 除 Pod 资 源 


陈述 式 对 象 配 置 管理 方式 下 的 删除 操作 与 创建 、 碍 看 及 更 新 操作 类 
似 ， 为 delete 命 令 使 用 -{ 选 项 指定 配置 清单 即 可 ， 例 如 ， 删 除 pod- 
example.yaml 文 件 中 定义 的 Pod 资 源 对 象 : 





~]$ kubectl delete -f pod-example.yaml 
pod "pod-example" deleted 





之 后 再 次 打印 相关 配置 清单 中 定义 的 资源 对 象 即 可 验 正 其 删除 的 结 
果 ， 例 如 : 





~]$ kubectl1 get -f pod-example.yaml 
No resources found. 


Error from server (NotFound): pods "pod-example" not found 


Pr 


3.5.2 ”声明 式 对 象 配 置 管理 方式 


陈述 式 对 象 配置 管理 机 制 中 ， 同 时 指定 的 多 个 资源 必须 进行 同一 种 
操作 ， 而 且 其 replace 命 令 是 通过 完全 符 换 现 有 的 活动 对 象 来 进行 资源 的 
更 新 操作 ， 对 于 生产 环境 来 说 ， 这 并 非 理想 的 选择 。 声 明 式 对 象 配置 操 
作 在 管理 资源 对 象 时 将 配置 信息 保存 于 目 标 对 象 的 注解 中 - 并 通过 比较 

活动 对 象 的 当前 配置 、 前 一 次 管理 操作 时 保存 于 注解 中 的 配置 ， 以 及 当 
前 命令 提供 的 配置 生成 更 新 补丁 从 而 完成 活动 对 象 的 补丁 式 更 新 操作 。 
此 类 管理 操作 的 常用 命令 有 apply 和 patch 等 。 


例如 ， 创 建 3.5.1 节 中 定义 的 主 容 右 使 用 “ikubernetes/myapp: V1” 镜 
像 的 Pod 资 源 对 象 ， 还 可 以 使 用 如 下 命令 进行 : 

















~]$ kubectl1 apply -f pod-example.yaml 
pod/pod-example created 











而 更 新 对 象 的 操作 ， 可 在 直接 修改 原 有 资源 清单 文件 后 再 次 对 其 执 
行 apply 命 令 来 完成 ， 例 如 ， 修 改 Pod 资 源 配置 清单 中 的 镜像 文件 
为 “ikubernetes/myapp: V2” 后 再 次 执行 如 上 的 apply 命 令 : 








~]$ kubectl1 apply -f pod-example.yaml 
pod/pod-example configured 





命令 结果 显示 资源 重新 配置 完成 并 且 已 经 生效 。 事 实 上 ， 此 类 操作 

也 完全 能 够 使 用 patch 命 令 直接 进行 补丁 操作 。 而 资源 对 象 的 删除 操作 依 
然 可 以 使 用 apply 命 令 ， 但 要 同时 使 用 全 令 的 格式 
为 “kubectl apply- et 1<labels>”。 需 要 注意 的 是 ， 此 命令 

弟 久 | 险 ， 因为 它 将 基于 标签 选择 器 过 滤 出 所 有 符 合 条 件 的 对 象 ， 并 检 
但 由 -f 指 定 的 目录 中 是 否 存 在 茶 配置 文件 已 经 定 义 了 相应 的 资源 对 象 ， 
那些 不 存在 相应 定义 的 资源 对 象 将 假 删除 。 因此 ， 删 除 资源 对 象 的 操作 
依然 建议 使 用 陈述 式 对 象 配置 方式 的 命令 “kubectl delete” 进 行 ， 这 样 的 
命令 格式 操作 目标 明确 且 不 易 出 现 偏差 














3.6 ”本 章 小 结 


本 章 介 绍 了 Kubernetes 系 统 上 常用 的 资源 对 象 类 型 及 其 管理 方式 ， 
在 说 明 kubect 命 令 令 行 工 具 的 基础 用 法 后 借助 于 Namespace 资 源 对 象 简 单 
说 明了 其 使 用 方式 ， 有 具体 如 下 。 


-Kubernetes 提 供 了 RESTfu 风 格 的 API， 它 将 各 类 组 件 均 抽 象 为 “ 资 
源 ”， 并 通过 属性 赋值 完成 实例 化 。 


:Kubernetes API 文 持 的 资源 类 型 众多 ， 包 括 Node、INamespace、 
Pod、Service、Deployment、ConfigMap 等 上 百 种 。 


.标准 格式 的 资源 配置 大 多 都 是 由 kind、apiVersion、metadata、 
和 status 等 一 级 属性 字段 组 成 ， 其 中 spec 征 由 用 户 定义 的 期 望 状 态 
status 则 是 由 系统 维护 的 当前 状态 。 


-Kubernetes API 主 要 提供 的 是 声明 式 对 象 配置 接口 ， 但 它 也 文 持 陈 
述 式 命令 及 陈述 式 对 象 配置 的 管理 方式 ， 


kubectl 命 令 功 能 众多 ， 它 将 通过 子 命 令 完成 不 同 的 任务 ， 如 


create、delete、edit、replace、apply 等 。 





.Namespace 和 Pod 是 Kubernetes 系 统 的 基础 资源 类 型 。 


第 4 章 ”管理 Pod 资 源 对 象 


Pod 是 Kubernetes 系 统 的 基础 单元 ， 是 资源 对 象 模型 中 可 由 用 户 创建 
或 部 署 的 最 小 组 件 ， 也 是 在 Kubernetes 系 统 上 运行 容器 化 应 用 的 资源 对 
象 。 其 他 的 大 多 数 资 源 对 象 都 是 用 于 文 撑 和 扩展 Pod 对 象 功能 的 ， 例 
如 ， 用 于 管控 Pod 运 行 的 StatefulSet 和 Deployment 等 控制 器 对 象 ， 用 于 暴 
露 Pod 应 用 的 Service 和 Ingress 对 象 ， 为 Pod 提 供 存储 的 PersistentVolume 存 
储 资源 对 象 等 。 这 些 资 源 对 象 大 体 可 分 为 有 限 的 几 个 类 别 ， 并 且 可 基于 
资源 清单 作为 资源 配置 文件 进行 陈述 式 或 声明 式 管理 。 本 章 将 描述 这 些 
类 别 ， 并 详细 介绍 Pod 资 源 的 基础 应 用 。 


4.1 容器 与 Pod 资 源 对 象 


现代 的 容器 技术 被 设计 用 来 运行 单个 进程 〈 包 括 子 进程 )》 时 ， 访 进 
程 在 容器 中 PID 名 称 空间 中 的 进程 号 为 1， 可 直接 接收 并 处 理 信 号 ， 于 
是 ， 在 此 进程 终止 时 ， 容 堪 即 终止 退出 。 知 要 在 一 个 容器 内 运行 多 个 进 
程 ， 则 需要 为 这 些 进 程 提 供 一 个 类 似 于 Linux 操 作 系 统 init 进 程 的 管控 类 
进程 ， 以 树 状 结构 完成 多 进程 的 生命 周期 管理 ， 例 如 ， 崩 尝 后 回收 相应 
的 系统 资源 等 。 单 容器 运行 多 进程 时 ， 通 常 还 需要 日 志 进 程 来 管理 这 些 
进程 的 日 志 ， 例 如 ， 将 它们 分 别 保存 于 不 同 的 目标 日 志文 件 等， 否则 用 
户 就 不 得 不 手动 来 分 拱 日 志 信息 。 因 此 ， 绝 大 多 数 场 景 中 都 应 该 于 一 个 
容器 中 仪 运行 一 个 进程 ， 它 将 日 志 信 息 直接 输出 全 容器 的 标准 输出 ， 文 
持 用 户 直 接 使 用 命令 (kubectl logs) 进行 获取 ， 这 也 是 Docker 及 
Kubernetes 使 用 容器 的 标准 方式 。 


不 过 ， 分 别 运 行 于 各 自 容器 的 进程 之 间 无 法 实现 基于 IPC 的 通信 机 
制 ， 此 时 ， 容 器 间 的 隔离 机 制 对 于 依赖 于 此 类 通信 方式 的 进程 来 说 却 又 
成 了 阻碍 。Pod 资 源 抽象 正 是 用 来 解决 此 类 问题 的 组 件 ， 前 文 已 然 多 次 
提 到 ，Pod 对 象 是 一 组 容器 的 集合 ， 这 些 容器 共享 Network、UTS 及 IPC 
名 称 空 间 ， 因 此 具有 相同 的 域名 、 主 机 名 和 网 络 接 口 ， 并 可 通过 IPC 直 
接 通信 。 为 一 个 Pod 对 象 中 的 各 容器 提供 网 络 名 称 空间 等 共享 机 制 的 是 
底层 基础 容器 pause， 图 4-1 所 示 为 一 个 由 三 个 容器 组 成 的 Pod 资 源 ， 各 容 
器 共享 Network、IPC 和 UTS 名 称 空间 ， 但 分 别 拥 有 各 目的 MNT、USR 和 
PID 名 称 空间 。 需 要 特别 强调 的 是 ， 一 个 Pod 对 象 中 的 多 个 容器 必须 运行 
dd 

















Pod 
pause 


PID 、Mount、User 


IPC UTS、 Network | 


Containerl Container2 
PID、 Mount、User|| PID、Mount、User 





图 4-1 ”Pod 内 的 容器 共享 Network、IPC 和 UTS 名 称 空间 


尽管 可 以 将 Pod 类 比 为 物理 机 或 VM， 但 一 个 Pod 内 通常 仅 应 该 运行 
一 个 应 用 ， 除 非 多 个 进程 之 间 具 有 密切 的 关系 。 这 也 意味 着 ， 实 践 中 应 
该 将 多 个 应 用 分 别 构建 到 多 个 而 非 单 个 Pod 中 ， 这 样 也 更 能 符合 容器 的 
轻 量化 设计 、 运 行 之 目的 。 


例如 ， 一 个 有 着 前 端 (application server) 和 后 端 〈database 

server) 的 应 用 ， 其 前 、 后 端 应 该 分 别 组 织 于 各 上 自 的 Pod 中 ， 而 非 同一 
Pod 的 不 同 容 器 中 。 这 样 做 的 好 处 在 于 ， 多 个 Pod 可 被 调度 至 多 个 不 同 的 
主机 运行 ， 提 高 了 资源 利用 率 。 另 外 ，Pod 也 是 Kubernetes 进 行 系统 规模 
伸缩 的 基础 单元 ， 分 别 运 行 于 不 同 Pod 的 多 个 应 用 可 独立 按 需 进行 规模 
变动 ， 这 就 增强 了 系统 架构 的 灵活 性 。 事 实 上 ， 前 、 后 端 应 用 的 规模 需 
求 通常 不 会 相同 ， 而 且 无 状态 应 用 (application server) 的 规模 变动 也 比 
有 状态 应 用 (database server) 容易 得 多 ， 将 它们 组 织 于 同一 Pod 中 时 将 
无 法 享受 这 种 便利 。 


不 过 ， 有 些 场景 要 求 必 须 于 同一 Pod 中 同时 运行 多 个 容器 。 此 时 ， 
这 些 分 布 式 应 用 《尤其 是 微服 务 架 构 中 的 多 个 服务 ) 必须 遵循 某 些 最 佳 
实践 机 制 或 基本 准则 。 事 实 上 ，Kubernetes 并 非 期 望 成 为 一 个 管理 系 
统 ， 而 是 一 个 文 持 这 些 最 佳 实践 的 网 开发 人 员 或 管理 人 员 提 供 更 高 级 别 
服务 的 系统 。 分 布 式 系统 设计 通常 包含 以 下 几 种 模型 。 


1) Sidecar pattern 〈 边 车 模型 或 跨 斗 模型 ) : 即 为 Pod 的 主 应 用 容器 
提供 协同 的 辅助 应 用 容器 ， 每 个 应 用 独立 运行 ， 最 为 典型 的 代表 是 将 主 
应 用 容器 中 的 日 志 使 用 agent 收 集 至 日 志 服 务 器 中 时 ， 可 以 将 agent 运 行 

















为 辅助 应 用 容器 ， 即 sidecar。 男 一 个 典型 的 应 用 是 为 主 应 用 容 右 中 的 
database server 启 用 本 地 缓存 ， 如 图 4-2 所 示 。 


rm 


人 UDS 人 Redis 
Backend D- 一 噩 ZS cache 


图 4-2 Sidecar pattern 


2) Ambassador pattern 〈 大 使 模型 ) 即 为 远程 服务 创建 一 个 本 地 
代理 ， 代 理应 用 运行 于 容器 中 ， 主 容器 中 的 应 用 通过 代理 容器 访问 远程 
服务 ， 如 图 4-3 所 示 。 一 个 典型 的 使 用 示例 是 主 应 用 容器 中 的 进程 访 
问 “ 一 主 多 从 ”模型 的 远程 Redis 应 用 时 ， 可 在 当前 Pod 容 器 中 为 Redis 服 务 
创建 一 个 Ambassador container， 主 应 用 容器 中 的 进程 直接 通过 localhost 
接口 访问 Ambassador container 妈 可。 即便 是 Redis 主 从 集群 架构 发 生变 
动 时 ， 也 仅 需 要 将 Ambassador container 加 以 修改 即 可 ， 主 应 用 容器 无 须 
对 此 做 出 任何 反应 。 
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ANode of Service 
Backend ® Discovery ——> (» 
MAIN CONTAINER NA AMBASSADOR 
localhost 
: (Pod) 


图 4-3 Ambassador pattern 


3) Adapter pattern 〈 适 配器 模型 ) : 此 种 模型 一 般 用 于 将 主 应 用 容 
器 中 的 内 容 进 行 标准 化 输出 ， 例 如 ， 日 志 数 据 或 指标 数据 的 输出 ， 这 有 
助 于 调用 者 统一 接收 数据 的 接口 ， 如 网 4-4 所 示 。 另 外 ， 某 应 用 滚动 升 
级 后 的 版 本 不 兼容 旧 的 版 本 时 ， 其 报告 信息 的 格式 也 存在 不 兼容 的 可 能 
性 ， 使 用 Adapter container 有 助 于 避免 那些 调用 此 报告 数据 的 应 用 发 生 错 


天。 
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Le 0 A Node Logging 
Backend Adapter ! 
MAIN CONTAINER 和 a ADAPTER : 
localhost or (~ 


图 4-4 Adapter pattern 


Kubernetes 系 统 的 Pod 资 源 对 象 用 于 运行 单个 容器 化 应 用 ， 此 应 用 称 
为 Pod 对 象 的 主 容器 (main container) ， 同 时 Pod 也 能 容纳 多 个 容器 ， 不 
过 人 额外 的 容器 一 般 工 作为 Sidecar 模 型 ， 用 于 辅助 主 容器 完成 工作 职能 。 


4.2 ”管理 Pod 对 和 象 的 容器 


一 个 Pod 对 象 中 至 少 要 存在 一 个 容器 ， 因 此 ，containers 字 上 段 是 定义 
Pod 时 其 艇 套 字 段 Spec 中 的 必 选 项 ， 用 于 为 Pod 指 定 要 创建 的 容器 列表 。 
进行 容器 配置 时 ，name 为 必 选 字段 ， 用 于 指定 容器 名 称 ，image 字 上 段 是 
为 可 选 ， 以 方便 更 高 级 别 的 管理 类 资源 (如 Deployment) 等 能 复 兰 此 字 
学 人 因此 ， 定 义 一 个 容器 的 基础 
EE 哥 如 下 : 








name: CONTAINER NAME 
image: IMAGE FILE NAME 





此 外 ， 定 义 容器 时 还 有 一 些 其 他 常用 的 字段 ， 例 如 ， 定 义 要 其 露 的 
东 口 、 改 变 独 像 运行 的 默认 程序 、 传递 环境 变量 、 定 义 可 用 的 系统 资源 
配额 等 。 


4.2.1 镜像 及 其 获取 策略 


各 工作 节点 负责 运行 Pod 对 象 ， 而 Pod 的 核心 功用 在 于 运行 容器 ， 
此 工作 节点 上 必须 配置 容器 运行 引擎 ， 如 Docker 等 。 启 动容 器 时 ， 容 器 
引擎 将 目 先 于 本 地 查找 指 定 的 镜像 文件 ， 不 存在 的 镜像 则 需要 从 指定 的 
镜像 仓库 〈Registry) 下 载 至 本 地 ， 如 图 4-5 所 示 。 


Docker daemon 





图 4-5 Docker 及 其 Registry 


Kubernetes 系 统 支 持 用 户 自 定义 镜像 文件 的 获取 策略 ， 例 如 在 网 络 
资源 较为 紧张 时 可 以 禁止 从 仓库 中 获取 镜像 文件 等 。 容 器 
jg a 于 为 其 指定 镜像 获取 策略 ， 它 的 可 用 值 包括 
i 


“Always: 镜像 标签 为 "latest" 或 镜像 不 存在 时 总 是 从 指定 的 仓库 中 
获取 镜像 。 





.IfNotPresent: 仅 当 本 地 镜像 缺失 时 方才 从 目标 仓库 下 载 镜像 。 
.Never: 禁止 从 仓库 下 载 镜 像 ， 即 仅 使 用 本 地 镜像 。 
下 面 的 资源 清单 中 的 容器 定义 了 如 何 使 用 nginx: latest 镜 像 ， 其 获 


取 策 略为 Always， 这 意味 着 每 次 局 动容 器 时 ， 它 都 会 到 镜像 仓库 中 获取 
最 新 版 本 的 镜像 文件 : 











apiVersion: v1 
kind: Pod 
metadata: 

name: nginx-pod 
spec: 

containers: 

- Name: nginx 

image: nginx:latest 
imagePullPolicy: Always 





对 于 标签 为 “latest” 的 镜像 文件 ， 其 默认 的 镜像 获取 策略 即 
为 “Always”， 而 对 于 其 他 标签 的 镜像 ， 其 默认 策略 则 为 “IfNotPresent”。 
需要 注意 的 是 ， 使 用 私有 仓库 中 的 镜像 时 通常 需要 由 Registry 服 务 器 完 
成 认证 后 才能 进行 。 认 证 过 程 要 么 需要 在 相关 市 点 上 交互 式 执行 docker 
login 命 令 来 进行 ， 要 么 就 是 将 认证 信息 定义 为 专 有 的 Secret 资 源 ， 并 配 
置 Pod 通 过 “imagePullSecretes” 字 段 调 用 此 认证 信息 完成 。 后 面 8.5 节 会 详 
细 介 绍 此 功能 及 其 实现 。 


4.2.2” 戏 露 问 口 


Docker 的 网 络 模型 中 ， 使 用 默认 网 络 的 容器 化 应 用 需 通 过 NAT 机 制 
将 其 “其 露 ”(expose〉 到 外 部 网 络 中 才能 被 其 他 厄 点 之 上 的 容器 客户 病 
所 访问 。 然 而 ，Kubernetes 系 统 的 网 络 模 型 中 ， 各 Pod 的 IP 地 址 处 于 同一 
网 络 平面 ， 无 论 是 否 为 容器 指定 了 要 骏 露 的 端口 ， 都 不 会 影响 集群 中 其 
他 节点 之 上 的 Pod 客 户 端 对 其 进行 访问 ， 这 就 意味 看 ， 任 何 监听 在 非 lo 
接口 上 的 端口 都 可 以 通过 Pod 网 络 直接 被 请 求 。 从 这 个 角度 来 说 ， 容 器 
端口 只 是 信息 性 数据 ， 它 只 是 为 集群 用 户 提 供 一 个 快速 了 解 相 关 Pod 对 
象 的 可 访问 站 口 的 途径， 而 且 显 式 指 定 容 器 端口 ， 还 能 为 其 赋予 一 个 名 
称 以 方便 调用 。 


容器 的 ports 人 字段 的 值 是 一 个 列表 ， 由 一 到 多 个 端口 对 象 组 成 ， 它 的 
常用 极 套 字段 包括 如 下 几 个 。 


containerPort <integer>: 必 选 字段 ， 指 定 在 Pod 对 象 的 卫 地 址 上 暴 
露 的 容器 端口 ， 有 效 范 围 为 《0，65536) ; 使 用 时 ， 应 该 总 是 指定 容器 
应 用 正常 监听 着 的 端口 。 


name <string>: 当前 端口 的 名 称 ， 必 须 符合 IANA_SVC_NAME 规 
范 且 在 当前 Pod 内 必须 是 唯一 的 ， 此 端口 名 可 被 Service 资 源 调用 。 


:protocol: 端口 相关 的 协议 ， 其 值 仅 可 为 TCP 或 UDP， 默 认为 
工 CP 。 











名 提示 。 可 以 通过 “kubectl explain pods.spec.containers.ports” 获 取 
ports 对 象 可 用 的 字段 列表 。 


下 面 的 资源 配置 清单 示例 (pod-example-with-port.,yaml) 中 定义 的 
pod-example 指 定 了 要 暴露 容器 上 TCP 的 80 端 口 ， 并 将 之 命名 为 http: 





apiVersion: v1 
kind: Pod 
metadata: 

name: pod-example 
spec: 

containers: 


- name: myapp 
image: ikubernetes/myapp:v1 
ports: 
- name: http 
containerPort: 80 
protocol: TCP 





然而 ，Pod 对 象 的 IP 地 址 仅 在 当前 集群 内 可 达 ， 它 们 无 法 直接 接收 
来 自 集 群 外 部 客户 并 的 请 求 流量 ， 尺 管 它们 的 服务 可 达 性 不 受 工作 市 点 
边界 的 约束 ， 但 依然 受制 于 集群 边界 。 一 个 简单 的 解决 方案 是 通过 其 所 
在 的 工作 节操 的 IP 地 址 和 端口 将 其 暴露 到 集群 外 部 ， 如 图 4-6 所 示 。 
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图 4-6 ”通过 hostIP 和 hostPort 暴 露 容器 服务 


"hostPort <integer>: 主机 端口 ， 它 将 接收 到 的 请 求 通 过 NAT 机 制 转 
发 至 由 containerPort 字 段 指定 的 容器 端口 。 


hostIP <string>: 主机 端口 要 绑 定 的 主机 IP， 默 认为 0.0.0.0， 即 主机 
之 上 所 有 可 用 的 IP 地 址 ; 考虑 到 托管 的 Pod 对 象 是 由 调度 器 调度 运行 
的 ， 工 作 节 点 的 IP 地 址 难以 明确 指定 ， 因 此 此 字段 通常 使 用 默认 值 。 


需要 注意 的 是 ，hostPort 与 NodePort 类 型 的 Service 对 象 暴露 端口 的 方 
式 不 同 ，NodePort 是 通过 所 有 节点 暴露 容器 服务 ， 而 hostPort 则 是 经 由 
Pod 对 象 所 在 节点 的 IP 地 址 来 进行 。 








4.2.3 目 定 义 运行 的 容 左 化 应 用 


由 Docker 镜 像 启 动容 器 时 运行 的 应 用 程序 在 相应 的 Dockerfile 中 由 
ENTRYPOINT 指 令 进 行 定义 ， 传 递 给 程序 的 参数 则 通过 CMD 指 令 指 
定 ，ENTRYPOINT 指 令 不 存在 时 ，CMD 可 用 于 同时 指定 程序 及 其 参 
数 。 例 如 ， 在 某 工作 节点 上 运行 下 面 的 命令 获取 ikubernetes/myapp: v1 
镜像 中 定义 的 CMD 和 ENTRYPOINT， 命 令 如 下 : 





~]$ docker inspect ikubernetes/myapp:v1 -f {{.Config.Cmd}} 

[nginx -g daemon off;] 

~]$ docker inspect ikubernetes/myapp:v1 -f {{.Config.Entrypoint}} 
[] 





容 划 的 command 字 段 能 够 指定 不 同 于 镜像 默认 运行 的 应 用 程序 ， 并 
且 可 以 同时 使 用 args 字 上 段 进行 参数 传 违 ， 它 们 将 履 产 镜像 中 的 默认 害 
义 。 不 过 ， 如 果 仅 为 容器 定义 了 args 字 段 ， 那 么 它 将 作为 参数 传递 给 镜 
像 中 默认 指定 运行 的 应 用 程序 ， 如 果 仪 为 容器 定义 了 command 字 段 ， 那 
么 它 将 履 盖 镜像 中 定义 的 程序 及 参数 ， 并 以 无 参数 方式 运行 应 用 程序 。 
例如 下 面 的 资源 清单 文件 将 镜像 ikubernetes/myapp: v1 的 默认 应 用 程序 
修改 为 了 “/bin/sh”"， 传 递 应 用 的 参数 修改 为 了 “-c while true; do sleep 
30; done”: 











apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-custom-command 
spec: 
containers: 
- name: myapp 
image: alpine:latest 
command: ["/bin/sh"] 
args: ["-c","while true; do sleep 30; done"] 








自 定 义 args， 也 是 向 容器 中 的 应 用 程序 传递 配置 信息 的 名 用 方式 之 
-， 对 于 非 云 原 生 〈cloud native) 的 应 用 程序 ， 这 几乎 也 是 最 简单 的 配 
置 方式 。 另 一 个 常用 的 方式 是 使 用 环境 变量 。 








4.2.4 环境 变量 


非 容器 化 的 传统 管理 方式 中 ， 复 茶 应 用 程序 的 配置 信息 多 数 由 配置 
文件 进行 指定 ， 用 户 可 借助 于 简单 的 文本 编辑 器 完成 配置 管理 。 然 而 ， 
对 于 容 髓 隅 离 出 的 环境 中 的 应 用 程序 ， 用 户 就 不 得 不 罕 透 容 需 边界 在 容 
天 内 进行 配置 编辑 并 进行 重 载 ， 这 种 方式 复杂 且 低 效 。 于 是 ， 由 环境 变 
量 在 容器 月 动 时 传递 配置 信息 束 成 为 一 种 备 受 青睐 的 方式 。 

















© 注意 ”这 种 方式 依赖 于 应 用 程序 支持 通过 环境 变量 进行 配置 
的 能 力 ， 否 则 ， 用 户 在 制作 Docker 镜 像 时 需要 通过 entrypoint 脚 本 完成 环 
境 变 量 到 程序 配置 文件 的 同步 。 


同 Pod 对 象 中 的 容 右 环境 变量 传递 数据 的 方法 有 两 种 : env 和 
envFrom， 这 里 重点 介绍 第 一 种 方式 ， 第 二 种 方式 将 在 介绍 ConfigMap 
和 Secret 资 源 时 进行 说 明 。 


通过 环境 变量 配置 容器 化 应 用 时 ， 需 要 在 容器 配置 段 中 骸 套 使 用 
env 字 段 ， 它 的 值 是 一 个 由 环境 变量 构成 的 列表 。 环 境 变 量 通 党 由 name 
和 value 字 段 构成 。 


name<string> : 环境 变量 的 名 称 ， 必 选 字 段 。 


value<string> : 传递 给 环境 变量 的 值 ， 通 过 $ (VAR_NAME) 引 
用 ， 逃 逸 格式 为 "$9$ (VAR_NAME) ”， 默 认 值 为 空 。 


下 面 配置 清单 中 定义 的 Pod 对 象 为 其 容 堪 flebeat 传 递 了 两 个 环境 变 
量 ，REDIS_HOST 定 义 了 filebeat 收 集 的 日 志 信 息 要 发 往 的 Redis 主 机 地 
址 ，LOG_LEVEL 则 定义 了 flebeat 的 日 志 级 别 : 














apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-env 
spec: 
containers: 
- name: filebeat 
image: ikubernetes/filebeat:5.6.5-alpine 
env: 


- name: REDIS_HOST 

value: db.ilinux.io:6379 
- Name: LOG_LEVEL 

value: info 








这 些 环境 变量 可 直接 注入 容器 的 shell 环 境 中 ， 无 论 它们 是 否 真 正 被 
i 使 用 printenv 一 类 的 命令 都 能 在 容 需 中 获取 到 所 有 环境 变量 的 列 








4.2.5 ”共享 节点 的 网 络 名 称 空 间 


同一 个 Pod 对 象 的 各 容器 均 运行 于 一 个 独立 的 、 隔 离 的 Network 名 称 
空间 中 ， 共 享 同一 个 网 络 协议 栈 及 相关 的 网 络 设备 ， 如 图 4-7a 所 示 。 也 
有 一 些 特 殊 的 Pod 对 象 需要 运行 于 所 在 节点 的 名 称 空 间 中 ， 执 行 系统 级 
例如 查看 和 操作 节点 的 网 络 资源 甚至 是 网 络 设 备 等 ， 如 图 
4-7b 所 示 。 
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图 4-7 ”Pod 对象 的 网 络 名 称 空间 


通常 ， 以 kubeadm 部 署 的 Kubernetes 集 群 中 的 kube-apiserver、kube- 
controller-manager、kube-scheduler， 以 及 kube-proxy 和 kube-flannel 等 通 
常 都 是 第 二 种 类 型 的 Pod 对 象 。 事 实 上 ， 仪 需要 设置 spec.hostNetwork 的 
eh 即 可 创建 共享 节点 网 络 名 称 空间 的 Pod 对 象 ， 如 下 面 的 配置 清 
修 \: 








apiVersion: v1 
kind: Pod 
metadata: 

name: pod-use-hostnetwork 
spec: 

containers: 

- name: myap 

image: ikubernetes/myapp:v1 


hostNetwork: true 





将 上 面 的 配置 清单 保存 于 配置 文件 中 ， 如 pod-use- 
hostnetwork.yaml， 将 其 创建 于 集群 上 ， 并 但 看 其 网 络 接口 的 相关 属性 信 
恩 以 验证 它 是 个 能 共享 使 用 工作 节点 的 网 络 名 称 空 间 : 





~]$ kubect1l apply -f pod-use-hostnetwork.yaml 


~]$ kubectl exec -it pod-use-hostnetwork -- sh 
/ # ifconfig 
etho Link encap:Ethernet Hwaddr 00:16:3E:08:1B:F4 


inet addr:172.16.0.68 Bcast:172.31.143.255 Mask:255.255.240.0 
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 





如 上 述 命令 的 结果 显示 所 示 ， 它 打印 出 的 是 工作 节点 的 网 络 设备 及 
其 相关 的 接口 信息 。 这 就 意味 着 ，Pod 对 象 中 运行 的 容器 化 应 用 也 将 监 
昕 于 其 所 在 的 工作 节点 的 IP 地 址 之 上 ， 这 可 以 通过 直接 问 
node03.ilinux.io 节 点 发 起 请 求 来 验证 : 








~]$ curl node03.ilinux.io 
Hello MyApp | Version: vi | <a href="hostname.html">Pod Name</a> 





另外 ， 在 Pod 对 象 中 时 还 可 以 分 别 使 用 spec.hostPID 和 spec.hostIPC 来 
共享 工作 节点 的 PID 和 IPC 名 称 空间 。 


4.2.6 ”设置 Pod 对 象 的 安全 上 下 文 
pod 对 象 的 安全 上 下 文 用 于 设 定 Pod 或 容器 的 权限 和 访问 控制 功能 ， 
其 支持 设置 的 常用 属性 包括 以 下 几 个 方面 。 


.基于 用 户 ID CUID) 和 组 ID (GID) 控制 访问 对 象 〈 如 文件 ) 时 的 
权限 。 


:以 特权 或 非特 权 的 方式 运行 。 

:通过 Linux Capabilities 为 其 提供 部 分 特权 。 
.基于 Seccomp 过 滤 进 程 的 系统 调用 。 
.基于 SELinux 的 安全 标签 。 

是 否 能 够 进行 权限 升级 。 


Pod 对 象 的 安全 上 下 文 定 义 在 spec.securityContext 字 段 中 ， 而 容器 的 
安全 上 下 文 则 定义 在 spec.containers[].securityContext 字 段 中 ， 且 二 者 可 
仍 套 使 用 的 字段 还 有 所 不 同 。 下 面 的 配置 清单 示例 为 busybox 容 如 定义 
LP 它 以 vid 为 1000 的 非特 权 用 户 运 行 容器 ， 并 禁止 权限 升 
级 : 











apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-securitycontext 
spec: 
containers: 
- name: busybox 
image: busybox 
command: ["/bin/sh","-c","sleep 86400"] 
securityContext: 
runAsNonRoot: true 
runAsUser: 1000 
allowPrivilegeEscalation: false 





将 上 面 的 配置 清单 保存 于 配置 文件 (如 pod-with- 
securitycontext.yaml 文 件 ) 中， 而 后 创建 于 集群 中 即 可 验证 容器 进程 的 


运行 者 身份 : 





$ kubect1 apply -f pod-with-securitycontext.yaml 


$ kubect1 exec pod-with-securitycontext -- ps aux 
PID USER TIME COMMAND 

1 1000 0:00 Sleep 86400 

14 1000 0:00 ps aux 





另外 ， 可 设置 的 安全 上 下 文 属性 还 有 fsGroup、seLinuxOptions、 
supplementalGroups、sysctls、capabilities 和 privileged 等 ， 有 日 Pod 和 容器 各 
自 支 持 的 字段 也 有 所 不 同 ， 感 兴趣 的 读者 可 按 需 对 各 属性 进行 测试 。 





4.3 标签 与 标签 选择 需 


实践 中 ， 随 着 同类 型 资源 对 象 的 数量 越 来 越 多 ， 分 类 管理 也 变 得 越 
来 越 有 必要 : 基于 简单 旦 直接 的 标准 将 资源 对 象 划分 为 多 个 较 小 的 分 
组 ， 无 论 是 对 开发 人 员 还 是 对 系统 工程 师 来 说 ， 都 能 提升 管理 效率 ， 这 
也 正 是 Kubernetes 标 签 (Label) 的 核心 功能 之 一 。 对 于 附带 标签 的 资源 
对 象 ， 可 使 用 标签 选择 器 (Label Selector) 挑选 出 符合 过 滤 条 件 的 资源 
以 完成 所 需要 的 操作 ， 如 关联 、 查 看 和 删除 等 。 





4.3.1 ”标签 概述 


标签 是 Kubernetes 极 具 特 色 的 功能 之 一 ， 它 能 够 附加 于 Kubernetes 的 
任何 资源 对 象 之 上 。 简 和 单 来 说 ， 标 签 就 是 “ 键 值 ” 类 型 的 数据 ， 它 们 可 于 
资源 创建 时 直接 指定 ， 也 可 随时 按 需 添加 于 活动 对 象 中 ， 而 后 即 可 由 标 
签 选 择 右 进行 匹配 度 检 查 从 而 完成 资源 挑选 。 一 个 对 象 可 拥有 不 止 一 个 
标签 ， 而 同一 个 标签 也 可 被 添加 至 多 个 资源 之 上 。 


实践 中 ， 可 以 为 资源 附加 多 个 不 同 纬度 的 标签 以 实现 灵活 的 资源 分 
组 管理 功能 ， 例 如 ， 版 本 标签 、 环 境 标 签 、 分 层 架构 标签 等 ， 用 于 交叉 
标识 同一 个 资源 所 属 的 不 同 版 本 、 环 境 及 架构 层级 等 ， 如 图 4-8 所 示 。 
下 面 是 较为 常用 的 标签 。 





版 本 标 
签 : "release": "stable"，"release": "canary", "release": "beta"。 
-环境 标 


签 : "environment": "dev"，"environment": "qa"，"environment": "prodnu 


:应 用 标签 : "app": wi", "app": "gs", "app": we "app": "Sc" 。 
染 构 层级 标 


"tier": "frontend", "tier": "backend", "tier": "cache"。 


:分 区 标签 : "partition": "customerA"，"partition": "customerB"。 


: 品 探 级 别 标签 : "track": "daily"，"track": "weekly"。 


app: ui app: as app: pc app: se app: os 
= 
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rel: canary 


Accout CPP:as | | Product Order 和 app: os 
Service Catalog Service <rel:canary 
pod pod pod 


图 4-8 ”多 维度 标签 使 用 示例 (图 片 来 源 : 《Kubernetes in action》 ) 
标签 中 的 键 名 称 通常 由 键 前 级 和 键 名 组 成 ， 其 中 键 前 级 可 选 ， 其 格 


式 形 如 “KEY_PREFIX/KEY_NAME”。 键 名 至 多 能 使 用 63 个 字符 ， 可 使 
用 字母 、 数 字 、 连 接 号 (-) 、 下 划 线 (_) 、 点 号 〈.) 等 字符 ， 并 且 只 
能 以 字母 或 数字 开头 。 键 前 绥 必 须 为 DNS 子 域名 格式 ， 且 不 能 超过 253 
个 字符 。 省 略 键 前 缀 时 ， 键 将 被 视 为 用 户 的 私有 数据 ， 不 过 由 
Kubernetes 系 统 组 件 或 第 三 方 组 件 上 自动 为 用 户 资源 添加 的 键 必须 使 用 键 
前 级， 而 “kubernetes.io/ 前 绥 则 预 留 给 Kubernetes 的 核心 组 件 使 用 。 


标签 中 的 键 值 必须 不 能 多 于 63 个 字符 ， 它 要 么 为 空 ， 要 么 是 以 字母 
或 数字 开头 及 结尾 ， 且 中 间 仅 使 用 了 字母 数字、 连接 号 (-) 、 下 划 
线 (_) 或 点 号 〈.) 等 字符 的 数据 。 





@ 实践 中 ， 建 议 键 名 及 键 值 能 做 到 “ 见 名 知 义 ”， 且 尽 可 
能 保持 简单 。 


4.3.2 ”管理 资源 标签 


创建 资源 时 ， 可 直接 在 其 metadata 中 舱 套 使 用 “labels” 字 段 以 定义 要 
附加 的 标签 项 。 例如， 下 面 的 Pod 资 源 清单 文件 示例 pod-with-labels.yaml 
中 使 用 了 两 个 标签 anv=qa 和 tier=frontend: 





apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-labels 
labels: 
env: qa 
tier: frontend 
spec: 
containers: 
- name: myapp 
image: ikubernetes/myapp:vi1 





基于 此 资源 清单 创建 出 定义 的 Pod 对 象 之 后 ， 即 可 在 “kubectl get 
pods” 命 令 中 使 用 “--show-labels” 选 项 ， 以 额外 显示 对 象 的 标签 信息 : 





~]$ kubectl1 apply -f pod-with-labels.yaml 
pod "pod-with-labels" created 
~]$ kubectl get pods --show-labels 


NAME READY STATUS RESTARTS AGE LABELS 
pod-example 1/1 Running 0 3h <none> 
pod-with-labels 1/1 Running 0 13s env=qa, tier=frontend 





标签 较 多 时 ， 在 “kubectl] get pods Ar EO keyl, key2, 
.…” 选 项 可 指定 显示 有 着 特 定 键 的 标签 信息 。 例 如 ， 仪 显示 各 pods 之 上 
的 以 env 和 tier 为 键 名 的 标签 








~]$ kubectl get pods -L env,tier 


NAME READY STATUS RESTARTS AGE ENV TIER 
pod-example 1/1 Running 2 3h 
pod-with-labels 1/1 Running 0 5m qa frontend 





“kubectl label” 命 令 可 以 直接 管理 活动 对 象 的 标签 ， 以 按 需 进行 添加 
或 修改 等 操作 。 例 如 ， 为 pod-example 添 加 env=production 标 签 : 





~]$ kubect1 label pods/pod-example env=production 
pod "pod-example" labeled 





不 过 ， 对 于 已 经 附带 了 指定 键 名 的 标签 ， 使 用 “kubectl label” 为 其 设 
定 新 的 键 值 时 需要 为 命令 同时 使 用 “--overwrite” 命 令 以 强制 履 善 原 有 的 
键 值 。 例 如 ， 将 pod-with-labels 的 env 的 值 修改 为 testing”: 





~]$ kubect1 label pods/pod-with-labels env=testing --overwrite 
pod "pod-with-labels" labeled 





用 户 操 期 望 对 菏 标 签 之 下 的 资源 集合 执行 茶 类 操作 ， 例 如 ， 碍 看 或 
删除 等 ， 则 需要 移 使 用 “标签 选择 器 ?挑选 出 满足 条 件 的 资源 对 象 。 





4.3.3 ”标签 选择 器 


标签 选择 器 用 于 表达 标签 的 查询 条 件 或 选择 标准 ，Kubernetes API 
目前 支持 两 个 选择 右 ， 基 于 等 值 天 系 (equality-based) 以 及 基于 集合 关 
系 (set-based) 。 例 如 ，env=production 和 env! =qa 是 基于 等 值 关 系 的 选 
择 器 ， 而 tier in (frontend，backend)〉 则 是 基于 集合 关系 的 选择 器 。 另 
外 ， 使 用 标签 选择 器 时 还 将 遵循 以 下 逻辑 。 


1) 同时 指定 的 多 个 选择 圳 之 间 的 逻辑 关系 为 与 ?操作 。 

2) 使 用 空 值 的 标签 选择 器 意味 着 每 个 资源 对 象 都 将 被 选中 。 

3) 空 的 标签 选择 需 将 无 法 选 出 任何 资源 。 

基于 等 值 关 系 的 标签 选择 器 的 可 用 操作 符 有 “=”==” 和 ”“! =” 三 种 ， 
其 中 前 两 个 意义 相同 ， 都 表示 "等 值 ? 关 系 ， 最 后 一 个 表示 “不 等 "天 


系 。“kubectl get" 命 令 的 “- 选项 能 够 指定 使 用 标签 选择 器 ， 例 如 ， 显 示 
键 名 env 的 值 不 为 qa 的 所 有 Pod 对 象 : 











~]$ kubectl get pods -1 "env!=qa" -L env 


NAME READY STATUS RESTARTS AGE ENV 
pod-example 1/1 Running 2 4h production 
pod-with-labels 1/1 Running 0 40m testing 





再 例如 ， 显 示 标 签 键 名 env 的 值 不 为 ga， 且 标签 键 名 tier 的 值 为 
frontend 的 所 有 Pod 对 象 : 





~]$ kubect1 get pods -1 "env!=qa,tier=frontend" -L env,tier 
NAME READY STATUS RESTARTS AGE ENV TIER 
pod-with-labels 1/1 Running 0 43m testing frontend 





基于 集合 关系 的 标签 选择 器 支持 in、notin 和 exists 三 种 操作 符 ， 它 们 
的 使 用 格式 及 意义 具体 如 下 。 


KEY in (VALUE1，VALUE2，...) : 指定 的 键 名 的 值 存在 于 给 定 
的 列表 中 即 满足 条 件 。 


:KEY notin (VALUE1，VALUE2，...) : 指定 的 键 名 的 值 不 存在 
于 给 定 的 列表 中 即 满足 条 件 。 


:KEY: 所 有 存在 此 键 名 标签 的 资源 。 
`! KEY: 所 有 不 存在 此 键 名 标签 的 资源 。 
例如 ， 显 示 标 签 键 名 env 的 值 为 production 或 dev 的 所 有 Pod 对 象 : 





~]$ kubect1 get pods -1 "env in (production,dev)" -L env 
NAME READY STATUS RESTARTS AGE ENV 
pod-example 1/1 Running 2 4h production 





再 如 ， 列 出 标签 键 名 env 的 值 为 production 或 dev， 且 不 存在 键 名 为 
tier 的 标签 的 所 有 Pod 对 象 : 





~]$ kubect1 get pods -1 "env in (production,dev), !tier' -L env,tier 
NAME READY STATUS RESTARTS AGE ENV TIER 
pod-example 1/1 Running 2 4h production 





Os 为 了 避免 shell 解 释 器 解析 叹 写 〈(! ) ， 必 须要 为 此 类 
表达 式 使 用 单 引号 。 


此 外 ，Kubernetes 的 诸多 资源 对 象 必 须 以 标签 选择 器 的 > 
Pod 资 源 对 象 ， 例 如 Service、Deployment 和 ReplicaSet 类 型 的 资源 等 
们 在 spec 字 上段 中 骸 套 使 用 骸 套 的 “selector” 字 上 段 ， 通 过 “matchLabels’ , 宁 指 
1 有 的 甚至 还 支持 使 用 “matchExpressions” 构 造 复 杂 的 标签 
过 择机 钊 


-matchLabels: 通过 直接 给 定 键 值 对 来 指定 标签 选择 器 。 


-matchExpressions: 基于 表达 式 指定 的 标签 选择 器 列表 ， 每 个 选择 
器 都 形 如 “{key: KEY_NAME,， operator: OPERATOR,， values: 
[VALUE1，VALUE2，...]}”， 选 择 器 列表 间 为 “多 辑 与 ?关系 ; 使 用 mn 或 
NotIn 操 作 符 时 ， 其 values 不 强制 要 求 为 非 空 ee 而 使 用 
Exists 或 DostNotExist 时 ， 其 values 必 须 为 空 








忌 


下 面 所 示 的 资源 清单 片断 是 一 个 示例 ， 它 同时 定义 了 两 类 标签 选择 





selector: 
matchLabels: 
component: redis 
matchExpressions: 


- {key: tier, operator: In, values: [cache]} 
- {key: environment, operator: Exists, values:} 





标签 赋予 了 Kubernetes 灵 活 操 作 资 源 对 象 的 能 力 ， 它 也 是 Service 和 
Deployment 等 核心 资源 类 型 得 以 实现 的 基本 前 提 。 


4.3.4 ” Pod 节点 选择 器 nodeSelector 


Pod 节 点 选择 器 是 标签 及 标签 选择 器 的 一 种 应 用 ， 和 它 能 够 让 Pod 对 象 
基于 集群 中 工作 市 点 的 标签 来 挑选 倾 回 运行 的 目标 节点 。 


Kubernetes 的 kube-scheduler 守 护 进 程 负责 在 各 工作 节点 中 基于 系统 
资源 的 可 用 性 等 标签 挑选 一 个 来 运行 待 创建 的 Pod 对 象 ， 默 认 的 调度 器 
是 default-scheduler。Kubernetes 可 将 所 有 工作 节点 上 的 各 系统 资源 抽象 
成 资源 池 统 一 分 配 使 用 ， 因此 用 广 无 须 关 ; Pod 对 象 的 具体 运行 位 置 也 
能 良好 工作 。 不 过 ， 事 情 总 有 例外 ， 比 如 仅 有 部 分 节点 拥有 被 Pod 对 象 
依赖 到 的 特殊 人 硬件 设备 的 情况 ， 如 GPU 和 SSD 等 。 即 便 如 此 ， 用 户 也 不 
应 该 静态 指定 Pod 对 象 的 运行 位 置 ， 而 是 让 scheduler 基 于 标签 和 标签 选 
择 堪 为 Pod 挑 选 匹 配 的 工作 节点 。 


Pod 对 象 的 spec.nodeSelector 可 用 于 定义 节点 标签 选择 器 ， i 事先 
为 特定 分 的 Node 资 源 对 象 设 定好 标签 ， 而 后 配置 Pod 对 象 通过 节点 标 
从 选 笃 器 提 # 行 匹配 检测 ， 从 而 完成 节点 杀 和 性 调度 。 


为 Node 资 源 对 象 附 加 标签 的 方法 同 Pod 资 源 ， 使 用 “kubectl label 
nodes/NODE”* 命 令 即 可 。 例 如 ， 可 为 node01.ilinux.io 和 node03.ilinux.io 节 
点 设置 “disktype=ssd” 标 签 以 标识 其 拥有 SSD 设 备 : 




















~]$ kubect1 label nodes nodeQ01.ilinux.io disktype=ssd 
node "node01.ilinux.io" labeled 
~]$ kubect1 label nodes node03.ilinux.io disktype=ssd 
node "node03.ilinux.io" labeled 








查看 具有 键 名 SSD 的 标签 的 Node 资 源 : 





~]$ kubect1 get nodes -1 'disktype' -L disktype 


NAME STATUS ROLES AGE VERSION DISKTYPE 
node01.ilinux.io Ready <none> 15d V1.12.1 ssd 
node03.ilinux.io Ready <none> 15d V1.12.1 ssd 





如 果 某 Pod 资 源 需 要 调度 全 这 些 具有 SSD 设 备 的 市 点 之 上 ， 那 么 只 
需要 为 其 使 用 spec.nodeSelector 标 签 选 择 器 即 可 ， 例 如 下 面 的 资源 清单 


文件 pod-with-nodeselector.yaml 示 例 : 





apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-nodeselector 
labels: 
env: testing 
spec: 
containers: 
- name: myapp 
image: ikubernetes/myapp:vi1 
nodeSelector: 
disktype: ssd 





将 如 上 资源 清单 中 定义 的 Pod 资 源 创建 于 集群 中 ， 通 过 查看 其 运行 
的 结 点 即 可 判定 调度 效果 。 


另外 ， 动 手 测 试 和 查看 过 节点 标签 的 读者 或 许 已 经 注意 到 了 ， 集 群 
中 的 每 个 节点 默认 已 经 附带 了 多 个 标签 ， 如 kubernetes.io/hostname、 
beta.kubernetes.io/os 和 beta.kubernetes.io/arch 等 。 这 些 标签 也 可 以 直接 由 
nodeSelector 使 用 ， 尤 其 是 希望 将 Pod 调 度 至 某 特定 节点 时 ， 可 以 使 用 
kubernetes.io/hostname 直 接 绑 定 至 相应 的 主机 即 可 。 不 过 ， 这 种 绑 定 至 
特定 主机 的 需求 还 有 一 种 更 为 简单 的 实现 方式 ， 即 使 用 spec.nodeName 
字段 直接 指定 目标 节点 。 











4.4 资源 注解 


除了 标签 〈label) 之 外 ，Pod 与 其 他 各 种 资源 还 能 使 用 资源 注解 
(annotation) 。 与 标签 类 似 ， 注 解 也 是 “ 键 值 ”类 型 的 数据 ， 不 过 它 不 能 
用 于 标签 及 挑选 Kubernetes 对 象 ， 仪 可 用 于 为 资源 提供 “元 数据 ”信息 。 
另外 ， 注 解 中 的 元 数据 不 受 字 符 数 量 的 限制 ， 它 可 大 可 小 ， 可 以 为 结构 
化 或 非 结 构 化 形式 ， 也 文 持 使 用 在 标签 中 蔡 止 使 用 的 其 他 字符 。 


资源 注解 可 由 用 户 手 动 添加 ， 也 可 由 工具 程序 自动 附加 并 使 用 它 
们 。 在 Kubernetes 的 新 版 本 中 〈alpha 或 beta 阶 段 ) 为 某 资源 引入 新 字段 
时 ， 常 以 注解 的 方式 提供 ， 以 避免 其 增删 等 变动 对 用 户 带 来 困扰 ， 一 旦 
确定 支持 使 用 它们 ， 这 些 新 增 字 上 段 束 将 再 引入 到 资源 中 并 淘汰 相关 的 注 
解 。 另 外 ， 为 资源 添加 注解 也 可 让 其 他 用 户 快速 了 解 资源 的 相关 信息 ， 
例如 其 创建 者 的 身份 等 。 以 下 为 常用 的 场景 案例 。 

.由 声明 式 配 置 层 〈 如 apply 命 令 ) 管理 的 字段 : 将 这 些 字 段 定 义 为 
注解 有 助 于 识别 由 服务 器 或 客户 端 设 定 的 默认 值 、 系 统 自 动 生 成 的 字 上 段 
以 及 由 自动 伸缩 系统 生成 的 字段 。 


构建 、 发 行 或 镜像 相关 的 信息 ， 例 如 ， 时 间 戳 、 及 行 ID、Git 分 
文 、PR 号 码 、 镜 像 哈 和 硕 及 仓库 地 址 等 。 


指向 日 志 、 监 控 、 分 析 或 审计 仓库 的 指针 。 


.由 客户 端 库 或 工具 程序 生成 的 用 于 调试 目的 的 信息 : 如 名 称 、 版 
本 、 构 建 信息 等 。 























-用户 或 工具 程序 的 来 源 地 信息 ， 例 如 ,来自 其 他 生态 系统 组 件 的 
相关 对 象 的 url。 


轻 量 化 深 动 升级 工具 的 元 数据 ， 如 config 及 checkpoints。 


:相关 人 员 的 电话 号 码 等 联系 信息 ， 或 者 指 问 类 似 信息 的 可 寻 址 的 
目录 条 目 ， 如 网 站 站 点 。 


“kubectl get-o yaml” 和 “kubect] describe” 命 令 均 能 显示 资源 的 注解 信 
上 县。 例如 下 面 的 命令 显示 的 pod-example 的 注解 信息 : 





~]$ kubectl1 describe pods pod-example 


Name : pod-example 

Namespace: default 

Node: node02.ilinux.i0o/172.16.0.67 
Start Time: Mon, 26 Feb 2018 18:40:53 +0800 
Labels: env=production 


Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"yv 
1","kind":"Pod","metadata":{"annotations":{}, "name":"pod-example", "namespa 
ce":"default"},"spec":{"containers":[{"image":"ikubernetes/m.. 

Status : Running 





pod-example 此 前 由 声明 式 配置 命令 apply 创 建 ， 因 此 它 在 注解 中 保 
存 了 如 上 的 相关 信息 以 便 在 下 次 资源 变动 时 进行 版 本 对 比 。 


annotations 可 在 资源 创建 时 使 用 “metadata.annotations” 字 段 指 定 ， 也 
可 随时 按 需 在 活动 的 资源 上 使 用 “kubectl annotate” 命 令 进 行 附 加 。 例 
如 ， 为 pod-example 重 新 进行 注解 : 





~]$ kubectl1 annotate pods pod-example ilinux.io/created-by="cluster admin" 
pod "pod-example" annotated 





查看 生成 的 注解 信息 : 





~]$ kubectl1 describe pods pod-example | grep "Annotations" 
Annotations: ilinux.io/created-by=cluster admin 





A ij 要 在 资源 创建 时 的 清单 中 指定 ， 那 么 使 用 类 似 如 下 的 方式 即 





apiVersion: v1 
kind: Pod 
metadata: 
name: pod-example 
annotations: 
ilinux.io/created-by: cluster admin 
spec: 


4.5 Pod 对 象 的 生命 周期 


Pod 对 象 自从 其 创建 开始 至 其 终止 退出 的 时 间 范 围 称 为 其 生命 周 
期 。 在 这 段 时 间 中 ，Pod 会 处 于 多 种 不 同 的 状态 ， 并 执行 一 些 操 作 ; 其 
中 ， 创 建 主 容器 (main container) 为 必需 的 操作 ， 其 他 可 选 的 操作 还 包 
括 运行 初始 化 容器 (init container) 、 容 器 启动 后 钩子 (post start 
hook) 、 容 器 的 存活 性 探测 (iveness probe) 、 就 绪 性 探测 (readiness 
probe) 以 及 容器 终止 前 钧 子 (pre stop hook) 等 ， 这 些 操 作 是 否 执 行 则 
取决 于 Pod 的 定义 ， 如 图 4-9 所 示 。 





4.5.1 Pod 的 相位 


无 论 是 类 似 前 面 几 节 中 的 由 用 户 手 动 创 建 ， 还 是 通过 Deployment 等 
控制 器 创建 ，Pod 对 象 总 是 应 该 处 于 其 生命 进程 中 以 下 几 个 相位 
(phase) 之 一 。 





.Pending: API Server 创 建 了 Pod 资 源 对 象 并 已 存 入 etcd 中 ， 但 它 尚 
未 被 调度 完成 ， 或 者 仍 处 于 从 仓库 下 载 镜像 的 过 程 中 。 


Running: Pod 已 经 被 调度 至 某 节点 ， 并 且 所 有 容器 都 已 经 被 
kubelet 创 建 完 成 。 


Succeeded: Pod 中 的 所 有 容器 都 已 经 成 功 终止 并 且 不 会 被 重启 。 


-Failed: 所 有 容 莫 都 已 经 终止 ， 但 至 少 有 一 个 容器 终止 失败 ， 即 容 
虱 返 回 了 非 0 值 的 退出 状态 或 已 经 被 系统 终止 。 
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0 二 流 入 于 5 
图 4-9 ”Pod 的 生命 周期 (图 片 来 源 : https://blog.openshift.com ) 


通常 


Unknown: API Server 无 法 正常 获取 到 Pod 对 象 的 状态 信息 ， 通 销 
是 由 于 其 无 法 与 所 在 工作 节点 的 kubelet 通 信 所 致 。 


Pod 的 相位 是 在 其 生命 周期 中 的 宏观 概述 ， 而 非 对 容器 或 Pod 对 象 的 
综合 汇总 ， 而 且 相 位 的 数量 和 含义 被 严格 界定 ， 筷 仅 包 含 上 面 列举 的 相 


位 值 。 














4.5.2 Pod 的 创建 过 程 


Pod 是 Kubernetes 的 基础 单元 ， 理 解 它 的 创建 过 程 对 于 了 解 系统 运作 
大 有 神 益 。 图 4-10 描 述 了 一 个 Pod 资 源 对 象 的 典型 创建 过 程 。 


1) 用 户 通 过 kubectl 或 其 他 API 客 户 端 提交 Pod Spec 给 API Server。 


2) API Server 尝 试 着 将 Pod 对 象 的 相关 信息 存 入 etcd 中 ， 待 写 入 操作 
执行 完成 ，API Server 即 会 返回 确认 信息 至 客户 端 。 


3) API Server 开 始 反映 etcd 中 的 状态 变化 。 


4) 所 有 的 Kubernetes 组 件 均 使 用 “watch” 机 制 来 跟踪 检查 API Server 
上 的 相关 的 变动 。 

5) kube-scheduler (调度 器 〉 通过 其 “watcher”* 觉 察 到 API Server 创 建 
了 新 的 Pod 对 象 但 尚未 绑 定 至 任何 工作 节点 。 


6) kube-scheduler 为 Pod 对 象 挑选 一 个 工作 节点 并 将 结果 信息 更 新 至 
API Server。 








create Pod 






write 





watch(new pod) 
bind pod 







write 


~ 


docker run 








watch(bound pod)' 






‘update podstatus! | ' 





write 


图 4-10 pod 资 源 对 象 创建 过 寺 程 《图 片 来 源 https:Wblog.heptio.comy ) 


7) 调度 结果 信息 由 API Server 更 新 至 etcd 存 储 系 统 ， 而 且 API Server 
也 开始 反映 此 Pod 对 象 的 调度 吉 果 。 


8) Pod 被 调度 到 的 目标 工作 节点 上 的 kubelet 尝 试 在 当前 节点 上 调用 
Docker 启 动容 器 ， 并 将 容器 的 结果 状态 回 送 至 API Server。 


9) API Server 将 Pod 状 态 信息 存 入 etcd 系 统 中 。 


10) 在 etcd 确 认 写 入 操作 成 功 完 成 后 ，API Server 将 确认 信息 发 送 至 
相关 的 kubelet， 事 件 将 通过 它 被 接受 。 





4.5.3 Pod 生 命 周 期 中 的 重要 行为 


除了 创建 应 用 容器 〈 主 容器 及 其 辅助 容器 之 外 ， 用 户 还 可 以 为 
Pod 对 象 定义 其 生命 周期 中 的 多 种 行为 ， 如 初始 化 容器 、 存 活性 探测 及 
就 绪 性 探测 等 。 


1. 初 始 化 容器 





初始 化 容器 (init container〉 即 应 用 程序 的 主 容器 启动 之 前 要 运行 
的 容器 ， 和 常用 于 为 主 容器 执行 一 些 预 置 操 作 ， 它 们 具有 两 种 典型 特征 。 


1) 初始 化 容器 必须 运行 完成 直至 结束 ， 知 某 初 始 化 容器 运行 失 
败 ， 那 么 Kubernetes 需 要 重启 它 直 到 成 功 完成 。 


2) 每 个 初始 化 容器 都 必须 按 定义 的 顺序 串 行 运行 。 





© 注意 如果 Pod 的 spec.restartPolicy 字 上 段 值 为 “Never”"， 那 么 运 
行 失败 的 初始 化 容器 不 会 被 重 局 。 

有 不 少 场景 都 需要 在 应 用 容器 启动 之 前 进行 部 分 初始 化 操作 ， 例 
如 ， 等 待 其 他 关联 组 件 服务 可 用 、 基 于 环境 变量 或 配置 模板 为 应 用 程序 
生成 配置 文件 、 从 配置 中 心 获取 配置 等 。 初 始 化 容器 的 典型 应 用 需求 具 
体 包含 如 下 几 种 。 


1) 用 于 运行 特定 的 工具 程序 ， 出 于 安全 等 方面 的 原因 ， 这 些 程序 
不 适 于 包含 在 主 容 划 镜像 中 。 


2) 提供 主 容器 镜像 中 不 具备 的 工具 程序 或 自 定 义 代码 。 


3) 为 容器 镜像 的 构建 和 部 车 人 员 提 供 了 分 离 、 独 立 工作 的 途径 ， 
使 得 他 们 不 必 协 同 起 来 制作 单个 镜像 文件 。 


4) 初始 化 容器 和 主 容器 处 于 不 同 的 文件 系统 视图 中 ， 因 此 可 以 分 
别 安 全 地 使 用 敏感 数据 ， 例 如 Secrets 资 源 。 


5) 初始 化 容器 要 先 于 应 用 容器 串 行 启动 并 运行 完成 ， 因 此 可 用 于 























延 后 应 用 容器 的 启动 直至 其 依赖 的 条 件 得 到 满足 。 


Pod 资 源 的 “spec.initContainers” 字 段 以 列表 的 形式 定义 可 用 的 初始 容 
器 ， 其 舰 套 可 用 字段 类 似 于 “spec.containers”。 下 面 的 资源 清单 仪 是 一 个 
忽 始 化 容器 的 使 用 示例 ， 读 者 可 自行 创建 并 观察 初始 化 容器 的 相关 状 





apiVersion: v1 
kind: Pod 
metadata: 
name: myapp-pod 
labels: 
app: myapp 
spec: 
containers: 
- name: myapp-container 
image: ikubernetes/myapp:v1 
initContainers: 
- name: init-something 
image: busybox 
command: ['sh', '-c', 'sleep 10'] 





2. 生 命 周 期 钩子 函数 


生命 周期 钩子 函数 (ifecycle hook) 是 编程 语言 〈 如 Angular) 中常 
用 的 生命 周期 管理 的 组 件 ， 它 实现 了 程序 运行 周期 中 的 关键 时 刻 的 可 见 
性 ， 并 赋予 用 户 为 此 采取 某 种 行动 的 能 力 。 类 似 地 ， 容 器 生命 周期 钩子 
使 它 能 够 感知 其 自身 生命 周 期 管理 中 的 事件 ， 并 在 相应 的 时 刻 到 来 时 运 
ee Kubernetes 为 容器 提供 了 两 种 生命 周期 


:postStart: 于 容器 创建 完成 之 后 立即 运行 的 钧 子 处 理 器 
(handler) ， 不 过 Kubernetes 无 法 确保 它 一 定 会 于 容器 中 的 
ENTRYPOINT 之 前 运行 。 


:preStop: 于 容器 终止 操作 之 前 立即 运行 的 钧 子 处 理 器 ， 它 以 同步 
的 方式 调用 ， 因 此 在 其 完成 之 前 会 阻 窗 删除 容器 的 操作 的 调用 。 


钩子 处 理 器 的 实现 方式 有 “Exec” 和 “HTTP” 两 种 ， 前 一 种 在 钩子 事 
件 触 发 时 直接 在 当前 容器 中 运行 由 用 户 定 义 的 命令 ， 后 一 种 则 是 在 当前 
容器 中 向 某 URL 发 起 HTTP 请 求 。 























postStart 和 preStop 处 理 器 定义 在 容器 的 spec.lifecycle 骨 套 字 7 段 中 ， 其 
使 用 方法 如 下 面 的 资源 清单 所 示 ， 读 者 可 自行 创建 相关 的 Pod 资 源 对 
象 ， 并 验证 其 执行 结 





apiVersion: v1 
kind: Pod 
metadata: 

name: lifecycle-demo 

spec: 

containers: 

- name: lifecycle-demo-container 
image: ikubernetes/myapp:v1 
lifecycle: 

postStart : 
exec: 
command: ["/bin/sh","-c","echo 'lifecycle hooks handler' > /usr/share/ 
nginx/html/test.htm]l"] 





2 HH 


3. 容 器 探测 


容器 探测 (container probe) 是 Pod 对 象 生命 周期 中 的 一 项 重要 的 日 
党 任务， 它 是 kubelet 对 容器 周期 性 执行 的 健康 状态 诊断 ， 诊 断 操作 由 容 
器 的 处 理 器 (handler) 进行 定义 。Kubernetes 支 持 三 种 处 理 器 用 于 Pod 探 
测 。 


ExecAction: 在 容 各 中 执行 一 个 命令 ， 并 根据 其 返回 的 状态 码 进行 
诊断 的 操作 称 为 Exec 探 测 ， 状 态 码 为 0 表示 成 功 ， 人 否则 即 为 不 健康 状 





"TCPSocketAction: 通过 与 容 髓 的 某 TCP 端 口 尝试 建立 连接 进行 诊 
上 晰 ， 端 口 能 够 成 功 打 开 即 为 正 稍 ， 否 则 为 不 健康 状态 。 


.HITPGetAction: 通过 向 容器 IP 地 址 的 某 指定 端口 的 指定 path 发 起 
HTTP GET 请 求 进行 诊断 ， 啊 应 人 码 为 2xx 或 3xx 时 即 为 成 功 ， 否 则 为 失 
败 。 


任何 一 种 探测 方式 都 可 能 存在 三 种 结果 : “Success”( 成 
功 ) 、“Failure”( 失 败 ) 或 “Unknown” (未 知 ) ， 只 有 第 一 种 结果 表示 
成 功 通 过 检测 。 


:kubelet 可 在 活动 容器 上 执行 两 种 类 型 的 检测 : 存活 性 检测 
(livenessProbe ) 和 就 绪 性 检测 (readinessProbe)。 





存活 性 检测 : 用 于 判定 容器 是 否 处 于 “运行 ”(Running) 状态 ; 一 
旦 此 类 检测 未 通过 ，kubelet 将 杀 死 容器 并 根据 其 restartPolicy 决 定 是 否 将 
其 重启 ; 未 定义 存活 性 检测 的 容器 的 默认 状态 为 “Success”"。 束 绪 性 检 
测 : 用 于 判断 容器 是 否 准 备 就 绪 并 可 对 外 提供 服务 ， 未 通过 检测 的 容器 
意味 着 其 尚未 准备 束 绪 ， 端 点 控制 器 〈 如 Service 对 象 ) 会 将 其 IP 从 所 有 
匹配 到 此 Pod 对 象 的 Service 对 象 的 问 点 列表 中 移 除 ;检测 通过 之 后 ， 会 
再 次 将 其 IP 添 加 至 端点 列表 中 。 





@ 存活 性 检测 和 就 绪 性 检测 相关 的 话题 在 后 文 的 章节 中 
还 会 有 进一步 的 介绍 。 


4.5.4 容器 的 重启 策略 


容 右 程序 发 生 崩 尝 或 容器 申请 超出 限制 的 资源 等 原因 都 可 能 会 导致 
Pod 对 象 的 终止 ， 此 时 是 否 应 该 重建 该 Pod 对 象 则 取决 于 其 重启 策略 
(restartPolicy) 属性 的 定义 。 


1) Always: 但 凡 Pod 对 象 终止 就 将 其 重启 ， 此 为 默认 设 定 。 
2) OnFailure: 仅 在 Pod 对 象 出 现 错误 时 方才 将 其 重启 。 
3) Never: 从 不 重启 。 


需要 注意 的 是 ，restartPolicy 适 用 于 Pod 对 象 中 的 所 有 容器 ， 而 且 它 
仅 用 于 控制 在 同一 节点 上 重新 启动 Pod 对 象 的 相关 容器 。 首 次 需要 重启 
的 容器 ， 将 在 其 需要 时 立即 进行 重启 ， 随 后 再 次 需要 重启 的 操作 将 由 
kubelet 延 迟 一 段 时 间 后 进行 ， 且 反复 的 重 局 操作 的 延迟 时 长 依次 为 10 
秒 、20 秒 、40 秒 、80 秒 、160 秒 和 300 秒 ，300 秒 是 最 大 延迟 时 长 。 事 实 
上 ， 一 旦 绑 定 到 一 个 节点 ，Pod 对 象 将 永远 不 会 被 重新 绑 定 到 另 一 个 节 
点 ， 它 要 么 被 重启 ， 要 么 终止 ， 直 到 节点 发 生 故 障 或 被 删除 。 

















4.5.5 ”Pod 的 终止 过 程 


Pod 对 象 代表 了 在 Kubernetes 集 群 节 点 上 运行 的 进程 ， 它 可 能 曾 用 于 
处 理 生 产 数 据 或 向 用 户 提供 服务 等 ， 于 是 ， 当 Pod 本 喘 不 再 具有 存在 的 
价值 时 ， 如 何 将 其 优雅 地 终止 就 显得 尤为 重要 了 ， 而 用 户 也 需要 能 够 在 
正常 提交 删除 操作 后 可 以 获知 其 何 时 开始 终止 并 最 终 完成 。 操 作 中 ， 当 
用 户 提 交 删 除 请 求 之 后 ， 系 统 束 会 进行 强制 删除 操作 的 宽 限 期 倒计时 ， 
并 将 TERM 信息 发 送 给 Pod 对 象 的 每 个 容器 中 的 主 进程 。 宽 限期 倒计时 
结束 后 ， 这 些 进程 将 收 到 强制 终止 的 KILEL 信 号 ，Pod 对 象 随即 也 将 由 
API Server 删 除 。 如 果 在 等 待 进程 终止 的 过 程 中 ，kubelet 或 容 右 管理 器 
i 那么 终止 操作 会 重新 获得 一 个 满 额 的 删除 宽 限 期 并 重新 执 
行 删除 操作 。 


如 图 4-11 所 示 ， 一 个 典型 的 Pod 对 象 终 止 流程 具体 如 下 。 
1) 用 户 发 送 删除 Pod 对 象 的 命令 。 


2) API 服 务 器 中 的 Pod 对 象 会 随 着 时 间 的 推移 而 更 新 ， 在 宽 限 期 内 
(默认 为 30 秒 ) ，Pod 被 视 为 “dead”。 


3) 将 Pod 标 记 为 “Terminating” 状 态 。 





4) (与 第 3 步 同 时 运行 )kubelet 在 监控 到 Pod 对 象 转 
为 “Terminating” 状 态 的 同时 启动 Pod 关 闭 过 程 。 


5) (与 第 3 步 同 时 运行 ) 站 上 控制 器 监控 到 Pod 对 象 的 关闭 行为 时 
将 其 从 所 有 匹配 到 此 端点 的 Service 资 源 的 端点 列表 中 移 除 。 
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用 Immediata ldeletion of pod 1 
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图 4-11 Pod 的 终止 过 程 


6) 如 有 果 当 前 Pod 对 象 定义 了 preStop 钓 子 处 理 费 ， 则 在 其 标记 
为 “terminating” 后 即 会 以 同步 的 方式 启动 执行 ， 如 若 宽 限期 结束 后 ， 
ee 则 第 2 步 会 被 重新 执行 并 额外 获取 一 个 时 长 为 2 秒 
入 小 宽 限 期 。 


7) Pod 对 象 中 的 容器 进程 收 到 TERM 信和 号 。 


8) 宽 限 期 结束 后 ， 知 存在 任何 一 个 仍 在 运行 的 进程 ， 那 么 Pod 对 象 
即 会 收 到 SIGKILL 信 号 。 


9) Kubelet 请 求 API Server 将 此 Pod 资 源 的 宽 限 期 设置 为 0 从 而 完成 删 
除 操作 ， 它 变 得 对 用 户 不 再 可 见 。 


默认 情况 下 ， 上 所 有 删除 操作 的 宽 限 期 都 是 30 秒 ， 不 过 ，kubectl 
delete 命 令 可 以 使 用 “--grace-period=<seconds>” 选 项 目 定 义 其 时 长 ， 知 使 
用 0 值 则 表示 直接 强制 删除 指定 的 资源 ， 不 过 ， 此 时 需要 同时 为 命令 使 
用 “--force” 选 项 。 








4.6 ”Pod 存 活性 探测 


有 不 少 应 用 程序 长 时 间 持 续 运行 后 会 逐渐 转 为 不 可 用 状态 ， 并 且 仅 
能 通过 重启 操作 恢复 ，Kubernetes 的 容器 存活 性 探测 机 制 可 发 现 诸如 此 
类 的 问题 ， 并 依据 探测 结果 结合 重启 策略 触发 后 续 的 行为 。 存 活性 探测 
是 隶属 于 容器 级 别 的 配置 ，kubelet 可 基于 它 判 定 何 时 需要 重启 一 个 容 
人 














Pod spec 为 容器 列表 中 的 相应 容器 定义 其 专用 的 探 针 (存活 性 探测 
机 制 ) 即 可 启用 存活 性 探测 。 目 前 ，Kubernetes 的 容器 支持 存活 性 探测 
的 方法 包含 以 下 三 种 : ExecAction、TCPSocketAction 和 
HITPGetAction.。 


4.6.1 设置 exec 探 针 


exec 类 型 的 探 针 通过 在 目标 容器 中 执行 由 用 户 自 定 义 的 命令 来 判定 
容器 的 健康 状态 ， 耕 命令 状态 返回 值 为 0 则 表示 “成 功 ” 通 过 检测 ， 其 值 
均 为 “失败 ”状态 。“spec.containers.livenessProbe.exec” 字 段 用 于 定义 此 关 
检测 ， 它 只 有 一 个 可 用 属性 “command”， 用 于 指定 要 执行 的 命令 。 下 面 
是 定义 在 资源 清单 文件 liveness-exec.yaml 中 的 示例 : 





apiVersion: v1 
kind: Pod 
metadata: 
Jabels: 
test: liveness-exec 
name: liveness-exec 
spec: 
containers: 
- name: liveness-exec-demo 
image: busybox 


args: ["/bin/sh", "-c", " touch /tmp/healthy; Sleep 60; rm -rf /tmp/healthy; 
sleep 600"] 
livenessProbe: 
exec: 
command: ["test", "-e", "/tmp/healthy"] 





上 面 的 资源 清单 中 定义 了 一 个 Pod 对 象 ， 基于 busybox 镜 像 局 到 一 | 
运行 “touch/tmp/healthy; sleep 60; rm-rf/tmp/healthy; sleep 600” 命 令 令 的 
容器 ， 此 命令 在 容器 启动 时 创建 /mp/healthy 文 什 ， 并 于 60 秒 之 后 将 其 删 
除 。 存 活性 探 针 运行 “test-e/tmp/healthy”* 命 令 a 的 存在 
性 ， 若 文件 存在 则 返回 状态 码 09， 表 示 成 功 通 过 测试 。 


首先 ， 执 行 类 似 如 下 的 命令 ， 创 建 Pod 对 象 liveness-exec: 





~]$ kubect1l apply -f liveness-exec.yaml 
pod "liveness-exec" created 





在 60 秒 之 内 使 用 “kubectl describe pods/liveness-exec” 查 看 其 详细 信 
上 息 ， 其 存活 性 探测 不 会 出 现 错误 。 而 超过 60 秒 之 后 ， 再 次 运行 “kubect 
describe pods/liveness-exec” 查 看 其 详细 信息 可 以 发 现 ， 存 活性 探测 出 现 
并 且 隔 更 长 一 段 时 间 之 后 再 查看 其 至 还 可 以 看 到 容器 重启 的 相 








Events 
Type Reason Age From Message 
Warning Unhealthy 45s (x3 over 1m) kubelet, node02.ilinux.io Liveness 
probe failed: 
Normal Pulling 14s (x2 over 2m) kubelet, node02.ilinux.io pulling 
image "busybox" 
Normal Killing 14s kubelet, nodeQ02.ilinux.io Killing 


container with id docker://liveness-demo:Container failed liveness probe.. 
Container will be killed and recreated. 

Normal Pulled 10s (x2 over 2m) kubelet, node02.ilinux.io 
Successfully pulled image "busybox" 





男 外 ， 输 出 信息 的 “Containers” 一 段 中 还 清晰 地 显示 了 容器 健康 状 
态 检测 及 状态 变化 的 相关 信息 : 容器 当前 处 于 “Running” 状 态 ， 但 前 一 
次 是 为 “Terminated”， 原 因 是 退出 码 为 137 的 错误 信息 ， 它 表示 进程 是 被 
外 部 信号 所 终止 的 。137 事 实 上 是 由 两 部 分 数字 之 和 生成 的 : 
128+signum， 其 中 signum 是 导致 进程 终止 的 信号 的 数字 标识 ，9 表 示 
SIGKILL, 这 意味 着 进程 是 被 强行 终止 的 : 

















lJiveness-exec-demo: 


State: Running 
Last State: Terminated 
Reason: Error 
Exit Code: 137 
Ready: True 
Restart Count: 1 
Liveness: exec [test -e /tmp/healthy] delay=0s timeout=1s period=10s 


#Success=1 #failure=3 














待 容器 重启 完成 后 再 次 查看 ， 容 器 已 经 处 于 正常 运行 状态 ， 直 到 文 
件 再 次 被 删除 ， 存 活性 探测 失败 而 重启 。 从 下 面 的 命令 显示 可 以 看 出 ， 
liveness-exec 在 4 分 钟 时 间 内 已 然 重启 了 两 次 : 








~]$ kubectl get pods liveness-exec 
NAME READY STATUS RESTARTS AGE 
Jiveness-exec 1/1 Running 2 4m 





需要 特别 说 明 的 是 ，exec 指 定 的 命令 运行 于 容器 中 ， 会 消耗 容 絮 的 


可 用 资源 配额 ， 必 外 ， 考 虑 到 探测 操作 的 效率 本 号 等 因素 ， 探 测 操作 的 
命令 应 该 尽 可 能 简单 和 轻 量 。 


4.6.2 ”设置 HTTP 探 针 


基于 HTTP 的 探测 (HTTPGetAction) 向 目标 容器 发 起 一 个 HTTP 请 
求 ， 根 据 其 啊 应 码 进行 结果 判定 ， 响 应 码 形 如 2xx 或 3xx 时 表示 检测 通 
过 。 “spec.containers.livenessProbe.httpGet” 字 上 段 用 于 定义 此 类 检测 ， 它 的 
可 用 配置 字段 包括 如 下 几 个 。 


:host<string> : 请 求 的 主机 地 址 ， 默 认为 Pod IP; 也 可 以 在 
httpHeaders 中 使 用 “Host: ”来 定义 。 


.port<string> : 请 求 的 端口 ， 必 选 字 段 。 





:httpHeaders<[]Object>: 自 定义 的 请 求 报 文 首 部 。 
.path<string> : 请 求 的 HTTP 资 源 路 径 ， 即 URL path。 


.Scheme: 建立 连接 使 用 的 协议 ， 仅 可 为 HITTP 或 HTTPS， 默 认为 
HTTP。 


下 面 是 一 个 定义 在 资源 清单 文件 liveness-http.yaml 中 的 示例 ， 它 通 
过 lifecycle 中 的 postStart hook 创 建 了 一 个 专用 于 httpGet 测 试 的 页 面 文件 
healthz: 





apiVersion: v1 
kind: Pod 
metadata: 

labels: 
test: liveness 

name: liveness-http 

spec: 

containers: 

- name: liveness-http-demo 
image: nginx:1.12-alpine 
ports: 

- name: http 
containerPort: 80 
lifecycle: 
postStart : 
exec: 
command: ["/bin/sh", "-c", " echo Healthy > /usr/share/nginx/html/ 
healthz"] 
livenessProbe: 
httpGet: 
path: /healthz 


port: http 
Scheme : HTTP 





0 A http ete, ts 请 求 的 资源 路 径 
为 “healthz”， 地 址 默认 为 PodIP， 端 口 使 用 了 容器 中 定义 的 端口 名 称 
HTTP， 这 地 是 明太 和 时 指明 要 可 的 这 出 口 的 用 途 之 一 。 痛 先 创 建 此 
Pody : 





~]$ kubect1l apply -f liveness-http.yaml 
pod "liveness-http" created 





而 后 合 看 其 健康 状态 检测 相关 的 信息 ， 健 康 状态 检测 正 第 时 ， 容 右 
也 将 正常 运行 : 





~]$ kubect1l describe pods liveness-http 
Containers : 
liveness-http-demo: 


Port: 80/TCP 
State: Running 
Started: Thu, 21 Aug 2018 12:55:41 +0800 
Ready: True 
Restart Count: 0 
Liveness: http-get http://:http/healthz delay=0s timeout=1s period=10s 


#Success=1 #failure=3 





接 下 来 借助 于 “kubectl exec” 命 令 删 除 经 由 postStart hook 创 建 的 测试 
页 面 healthz: 





$ kubect1 exec liveness-http rm /usr/share/nginx/html/healthz 





而 后 再 次 使 用 “kubectl describe pods liveness-http” 查 看 其 详细 的 状态 
人 可 以 表明 探测 测试 失败 ， 容 器 被 杀 挥 后 进行 了 
新 创建 : 








Events: 
Warning Unhealthy 28s (x3 over 48s) kubelet, node02.ilinux.io Liveness 
probe failed: HTTP probe failed with statuscode: 404 
Normal Killing 28s kubelet, node02.ilinux.io Killing 


container with id docker://liveness-demo:Container failed liveness probe.. Cor 





一 般 来 说 ，HTTP 类 型 的 探测 操作 应 该 针对 专用 的 URL 路 径 进行 ， 
例如 ， 前 面 示例 中 特别 为 其 准备 的 “/healthz?。 另 外 ， 此 URL 路 径 对 应 的 
Web 资 源 应 该 以 轻 量化 的 方式 在 内 部 对 应 用 程序 的 各 关键 组 件 进行 全 面 
检测 以 确保 它们 可 正常 向 客户 端 提供 完整 的 服务 。 


需要 注意 的 是 ， 这 种 检测 方式 仅 对 分 层 架构 中 的 当前 一 层 有 效 ， 例 
如 ， 它 能 检测 应 用 程序 工作 正常 与 否 的 状态 ， 但 重启 操作 却 无 法 解决 其 
后 端 服务 〈 如 数据 库 或 缓存 服务 ) 导致 的 故障 。 此 时 ， 容 器 可 能 会 被 一 
次 次 的 重启 ， 直 到 后 市 服务 恢复 正 党 为止。 其 他 两 种 检测 方式 也 存在 类 
以 的 问题 。 

















4.6.3 ”设置 TCP 探 针 


基于 TCP 的 存活 性 探测 (TCPSocketAction〉 用 于 向 容器 的 特定 端口 
发 起 TCP 请 求 并 尝试 建立 连接 进行 结果 判定 ， 连 接 建立 成 功 即 为 通过 检 
测 。 相 比较 来 说 ， 它 比 基 于 HTTP 的 探测 要 更 高 效 、 更 节约 资源 ， 但 精 
准 度 略 低 ， 毕 况 连 接 建立 成 功 未 必 意味 着 页 面 资源 可 
用 。 “spec.containers.livenessProbe.tcpSocket* 字 上 段 用 于 定义 此 类 检测 ， 它 
主要 包含 以 下 两 个 可 用 的 属性 。 


1) host<string>: 请 求 连接 的 目标 IP 地 址 ， 默 认为 Pod IP。 
2) port<string>: 请 求 连 接 的 目标 端口 ， 必 选 字段 。 
下 面 是 一 个 定义 在 资源 清单 文件 liveness-tcp.yaml 中 的 示例 ， 它 问 


Pod IP 的 80/tcp 端 口 发 起 连接 请 求 ， 并 根据 连接 建立 的 状态 判定 测试 结 
果 : 








apiVersion: v1 
kind: Pod 
metadata: 

labels: 
test: liveness 

name: liveness-tcp 

spec: 

containers: 

- name: liveness-tcp-demo 
image: nginx:1.12-alpine 
ports: 

- name: http 
containerPort: 80 
livenessProbe: 
tcpSocket : 
port: http 











这 里 不 再 给 出 其 具体 的 创建 与 测试 过 程 ， 有 兴趣 的 读者 可 自行 进行 
测试 。 


4.6.4 存活 性 探测 行为 属性 


使 用 kubectl describe 命 令 查看 配置 了 存活 性 探测 的 Pod 对 象 的 详细 信 
恩 时 ， 其 相关 容器 中 会 输出 类 似 如 下 一 行 的 内 容 : 





Liveness: exec [test -e /tmp/healthy] delay=0s timeout=1s period=10s 
#success=1 #failure=3 





它 给 出 了 探测 方式 及 其 额外 的 配置 属性 delay、timeout、period、 
success 和 failure 及 其 各 自 的 相关 属性 值 。 用 户 没 有 明确 定义 这 些 属性 字 
段 时 ， ds 目的 默认 值 ， 例 如 上 面 显示 出 的 设 定 。 这 些 属性 信 
息 可 通过 “spec.containers.livenessProbe” 的 如 下 属 性 字段 来 给 出 。 





:initialDelaySeconds<integer> : 存活 性 探测 延迟 时 长 ， 即 容器 启动 
多 久之 后 再 开始 第 一 次 探测 操作 ， 显 示 为 delay 属 性 ;默认 为 0 秒 ， 即 容 
恬 局 动 后 立刻 便 开始 进行 探测 。 


-timeoutSeconds<integer> : 存活 性 探测 的 超时 时 长 ， 显 示 为 timeout 
属性 ， 默 认为 1s， 最 小 值 也 为 1s。 


:periodSeconds<integer> : 存活 性 探测 的 频 度 ， 显 示 为 period 属 性 ， 
默认 为 10s， 最 小 值 为 1s; 过 高 的 频率 会 对 Pod 对 象 市 来 较 大 的 额外 开 
销 ， 而 过 低 的 频率 又 会 使 得 对 错误 的 反应 不 及 时 。 


处 于 失败 状态 时 ， 探 测 操作 至 少 连 续 
es 通过 检测 ， 显 示 为 #success 属 性 ， 默 认 值 为 1， 
最 小 1 


failureThreshold: 处 于 成 功 状态 时 ， 探 测 操作 至 少 连 续 多 少 次 的 失 
败 才 被 视 为 是 检测 不 通过 ， 显 示 为 #failure 属 性 ， 默 认 值 为 3， 最 小 值 为 
18 


例如 ， 这 里 可 将 4.6.1 节 中 清单 文件 中 定义 的 探测 示例 重新 定义 为 如 
下 所 示 的 内 容 : 





spec: 
containers: 
livenessProbe: 

exec: 
command: ["test", "-e", "/tmp/healthy"] 

initialDelaySeconds 5s 
timeoutSeconds 2s 
periodSeconds 5s 





根据 修改 的 清单 再 次 创建 Pod 对 象 并 进行 效果 测试 ， 可 以 从 输出 的 
详细 信息 中 看 出 Liveness 已 经 更 新 到 目 定 义 的 属性 ， 其 内 容 如 下 所 示 。 
具体 过 程 这 里 不 再 给 出 ， 请 感 兴趣 的 读者 目 行 测试 。 





Liveness: exec [test -e /tmp/healthy] delay=5s timeout=2s period=5s 
#success=1 #failure=3 





4.7 ”Pod 束 绪 性 探测 


Pod 对 象 局 动 后 ， 容 器 应 用 通常 需要 一 段 时 间 才 能 完成 其 初始 化 过 
程 ， 例 如 加 载 配置 或 数据 ， 甚 至 有 些 程序 需要 运行 条 类 的 预 热 过 程 ， 大 
在 此 阶段 完成 之 前 即 接 入 客户 端的 请 求 ， 势 必 会 因为 等 待 太 久 而 影 啊 用 
户 体验 。 因 此 ， 应 该 避免 于 Pod 对 象 局 动 后 立即 让 其 处 理 客户 端 请 求 ， 
而 是 等 待 容 占 初始 化 工作 执行 完成 并 转 为 “ 束 绪 ”状态 ， 尤 其 是 存在 其 他 
提供 相同 服务 的 Pod 对 象 的 场景 更 是 如 此 。 


与 存活 性 探测 机 制 类 似 ， 束 绪 性 探测 是 用 来 判断 容器 就 绪 与 否 的 周 
期 性 (默认 周期 为 10 秒 钟 ) 操作 ， 它 用 于 探测 容器 是 否 已 经 初始 化 完成 
并 可 服务 于 客户 端 请 求 ， 探 测 操作 返回 “success” 状 态 时 ， 即 为 传递 容 髓 
已 经“ 就绪” 的 信和 号。 


与 存活 性 探测 机 制 相 同 ， 就 绪 性 探测 也 支持 Exec、HTTP GET 和 
TCP Socket 三 种 探测 方式 ， 且 各 自 的 定义 机 制 也 都 相同 。 但 与 存活 性 探 
测 触发 的 操作 不 同 的 是 ， 探 测 失 败 时 ， 就 绪 性 探测 不 会 杀 死 或 重启 容器 
以 保证 其 健康 性 ， 而 是 通知 其 尚未 就 绕 ， 并 触发 依赖 于 其 就 绪 状 态 的 操 
作 “〔〈 例 如 ， 从 Service 对 象 中 移 除 此 Pod 对 象 ) 以 确保 不 会 有 客户 端 请 求 
接 入 此 Pod 对 象 。 不 过 ， 即 便 是 在 运行 过 程 中 ，Pod 就 绪 性 探测 依然 有 其 
价值 所 在 ， 例 如 Pod A 依赖 到 的 Pod B 因 网 络 故障 等 原因 而 不 可 用 时 ， 
和 
Yo 


将 容器 定义 中 的 livenessProbe 字 段 名 蔡 换 为 readinessProbe 即 可 定义 
出 就 绪 性 探测 的 配置 ， 一 个 简单 的 示例 如 下 面 的 配置 清单 (readiness- 
exec.yaml) 所 示 ， 它 会 在 Pod 对 象 创建 完成 5 秒 钟 后 使 用 test-e/tmp/ready 
0 8 




















apiVersion: v1 
kind: Pod 
metadata: 
Jabels: 
test: readiness-exec 
name: readiness-exec 
spec: 
containers: 
- name: readiness-demo 


Image: busybox 


args: ["/bin/sh", "-c", "while true; do rm -f /tmp/ready; Sleep 30; touch 
/tmp/ready; sleep 300; done"] 
readinessProbe: 
exec: 
command: ["test", "-e", "/tmp/ready"] 


initialDelaySeconds: 5 
periodSeconds: 5 





A i 使 用 “kubectl create” 命 令 将 资源 配置 清单 定义 的 资源 创建 到 
群 中 : 





~]$ kubect1l create -f readiness-exec.yaml 
pod/readiness-exec created 





接着 ， 运 行 “kubectl get-w” 命 令 监 视 其 资源 变动 信息 ， 由 如 下 命令 
结果 可 知 ， 尽 官 Pod 对 象 处 于 “Running” 状 态 ， 但 直到 就 绪 探 测 命令 执行 
成 功 后 ，Pod 资 源 才 转 为 “就 绪 ”: 





~]$ kubect1 get pods -1 test=readiness-exec -Ww 


NAME READY STATUS RESTARTS AGE 
readiness-exec 0/1 Running 0 15S 
readiness-exec 1/1 Running 0 41S 








男 外 ， 还 可 从 Pod 对 象 的 详细 信息 中 得 到 类 似 如 下 的 表示 其 已 经 处 
于 就 绪 状 态 的 信息 片断 : 





Ready : True 

Restart Count: 0 

Readiness: exec [test -e /tmp/ready] delay=5s timeout=1s period=5s #success=1 
#failure=3 





这 里 需要 特别 提醒 读者 的 是 ， 示 定义 束 绪 性 探测 的 Pod 对 象 在 Pod 进 
入 “Running” 状 态 后 将 立即 就 绪 ， 在 容器 需要 时 间 进 行 初 始 化 的 场景 
中 ， 在 应 用 真正 就 绪 之 前 必然 无 法 正常 响应 客户 端 请 求 ， 因 此 ， 生 产 实 
践 中 ， 必 须 为 关键 性 Pod 资 源 中 的 容器 定义 就 绪 性 探测 机 制 。 其 探测 机 
制 的 定义 请 参考 4.6 节 中 的 定义 。 














4.8 资源 需求 及 资源 限制 


在 Kubernetes 上 ， 可 由 容器 或 Pod 请 求 或 消费 的 “计算 资源 ”是 指 CPU 
和 内 存 (RAM) ， 这 也 是 目前 仅 有 的 受 文 持 的 两 种 类 型 。 相 比较 来 
说 ，CPU 属 于 可 压缩 〈compressible) 型 资源 ， 即 资源 额度 可 按 需 收 
缩 ， 而 内 存 〈 当 前 ) 则 是 不 可 压缩 型 资源 ， 对 其 执行 收缩 操作 可 能 会 导 
致 某 种 程度 的 问题 。 


目前 来 说 ， 资 源 隔 离 尚 且 属 于 容 圳 级别，CPU 和 内 存 资源 的 配置 再 
要 在 Pod 中 的 容器 上 进行 ， 每 种 资源 均 可 由 “requests” 属 性 定义 其 请 求 的 
确保 可 用 值 ， 即 容 圳 运行 可 能 用 不 到 这 些 额 度 的 资源 ， 但 用 到 时 必须 要 
确保 有 如 此 多 的 资源 可 用 ， 而 “limits” 属 性 则 用 于 限制 资源 可 用 的 最 大 
值 ， 即 人 硬 限制 ， 如 图 4-12 所 示 。 不 过 ， 为 了 表述 方便 ， 人 们 通常 仍然 把 
资源 配置 称 作 Pod 资 源 的 请 求 和 限制 ， 只 不 过 它 是 指 Pod 内 所 有 容器 上 茶 
种 类 型 资源 的 请 求 和 限制 的 总 和 。 

















Maximum CPU resources for container 








cpu.requests=200m cpu.limits=500m 








3 Le -和 


Guaranteed resources Throttled resources 
图 4-12 ”容器 资源 需求 及 资源 限制 示意 图 


在 Kubernetes 系 统 上 ，1 个 单位 的 CPU 相当 于 虚拟 机 上 的 1 颗 虚 拟 
CPU (vCPU) 或 物理 机 上 的 一 个 超 线程 (Hyperthread， 或 称 为 一 个 逻 
辑 CPU)〉， 它 支持 分 数 计量 方式 ， 一 个 核心 (1lcore〉 相当 于 1000 个 微 核 
心 Cmillicores) ， 因 此 500m 相 当 于 是 0.5 个 核心 ， 即 二 分 之 一 个 核心 。 
内 存 的 计量 方式 与 日 党 使 用 方式 相同 ， 默 认 单位 是 字 节 ， 也 可 以 使 用 
E、P、T、G、M 和 K 作 为 单位 后 级 ， 或 Ei、Pi、Ti、Gi、Mi 和 Ki 形式 的 
单位 后 级 。 





4.8.1 资源 需求 


下 面 的 示例 中 ， 自 主 式 Pod 要 求 为 stress 容 器 确保 128Mi 的 内 存 及 五 
分 之 一 个 CPU 核心 (200m) 资源 可 用 ， 它 运行 stress-ng 镜 像 启动 一 个 进 
程 (-m1) 进行 内 存 性 能 压力 测试 ， 满 载 测 试 时 它 也 会 尽 可 能 多 地 占用 
CPU 资 源 ， 男 外 再 启动 一 个 专用 的 CPU 压 力 测 试 进程 (-c 1) 。stress-ng 
是 一 个 多 功能 系统 压力 测试 具 ，master/worker 模 型 ，Master 为 主 进 程 ， 
负责 生成 和 控制 子 进程 ，worker 是 负责 执行 各 类 特定 测试 的 子 进程 ， 例 
如 测试 CPU 的 子 进程 ， 以 及 测试 RAM 的 子 进程 等 : 





apiVersion: v1 
kind: Pod 
metadata: 
name: stress-pod 
spec: 
containers: 
- name: stress 
image: ikubernetes/ stress-ng 
command: ["/usr/bin/stress-ng", "-m 1", "-c 1", "-metrics-brief"] 
resources: 
requests: 
memory: "128Mi" 
cpu: "200m" 





上 面 的 配置 清单 中 ， 其 请 求 使 用 的 CPU 资源 大 小 为 200m， 这 意味 
独 一 个 CPU 核心 足以 确保 其 以 期 望 的 最 快 方式 运行 。 妇 外 ， 配 置 清 单 中 
期 望 使 用 的 内 存 大 小 为 128Mi， 不 过 其 运行 时 未 必 真 的 会 用 到 这 人 么 多 。 
考虑 到 内 存 为 非 压缩 型 资源 ， 其 超出 指定 的 大 小 在 运行 时 存在 被 OOM 
可 能 性 ， 于 是 请 求 值 也 应 该 束 是 其 理想 中 使 用 的 内 存 空 间 上 
限 。 


接 下 来 创建 并 运行 此 Pod 对 其 资源 限制 效果 进行 检查 。 需 要 特别 说 
明 的 是 ， 笔 者 当前 使 用 的 系统 环境 中 ， 每 个 节点 的 可 用 CPU 核心 数 均 为 
8， 物 理 内 存 空 间 为 16GB: 








~]$ kubectl create -f pod-resources-test.yaml 





而 后 在 Pod 资 源 的 容器 内 运行 top 命 令 观 察 其 CPU 及 内 存 资源 的 占用 
状态 ， 如 下 所 示 ， 其 中 {stress-ng-vm} 是 执行 内 存 压 测 的 子 进 程 ， 它 默认 


使 用 256m 的 内 存 空间 ，f{stress-ng-cpu} 是 执行 CPU 压 测 的 专用 子 进程 : 





~]$ kubect1 exec stress-pod -- top 

Mem: 2884676K used, 13531796K free, 27700K shrd, 2108K buff, 1701456K cached 
CPU: 25% usr 0% sys 0% nic 74% idle 0% io 0% rd 0% sirq 

Load average: 0.57 0.60 0.71 3/435 15 

PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 


9 8 root R 262m 2% 6 13% {stress-ng-vm} /usr/bin/stress-ng 
也 1 root R 6888 0% 3 13% {stress-ng-cpu} /usr/bin/stress-ng 
让 © root S 6244 0% 1 0% /usr/bin/stress-ng -Cc 1 -m 1 --met 





top 命 令 的 输出 结果 显示 ， 每 个 测试 进程 的 CPU 占 用 率 为 13% (实际 
为 12.5%) ，f{stress-ng-vm} 的 内 存 占 用 量 为 262m (VSZ) ， 此 两 项 资源 
占用 量 都 远 超 其 请 求 的 用 量 ， 原 因 是 stress-ng 会 在 可 用 的 范围 内 尽量 多 
地 占用 相关 的 资源 。 两 个 测试 线程 分 布 于 两 个 CPU 核 心 以 满载 的 方式 运 
行 ， 系 统 共 有 8 个 核心 ， 因 此 其 使 用 率 为 25% (2/8) 。 另 外 ， 节 点 上 的 
内 存 资源 充裕 ， 虽 然 容器 的 内 存 用 量 远 超 128M， 但 它 依然 可 运行 。 一 
且 资 源 基 张 时 ， 节 点 仅 保 证 容器 有 五 分 之 一 个 CPU 核心 可 用 ， 对 于 有 着 
8 个 核心 的 节点 来 说 ， 它 的 占用 率 为 2.5%， 于 是 每 个 进程 为 1.25%， 多 占 
用 的 资源 会 被 压缩 。 内 存 为 非 可 压缩 型 资源 ， 所 以 此 Pod 在 内 存 资源 紧 
张 时 可 能 会 因 OOM 被 杀 死 (killed) 。 


对 于 压缩 型 的 资源 CPU 来 说 ， 示 定义 其 请 求 用 量 以 确保 其 最 小 的 可 
用 资源 时 ， 它 可 能 会 被 其 他 的 Pod 资 源 压缩 至 极 低 的 水 平 ， 甚 至 会 达到 
Pod 不 能 够 被 调度 运行 的 境地 。 而 对 于 非 压缩 型 资源 来 说 ， 内 存 资源 在 
任何 原因 导致 的 紧缺 情形 下 都 有 可 能 导致 相关 的 进程 被 杀 死 。 因 此 ， 在 
Kubernetes 系 统 上 运行 关键 型 业务 相关 的 Pod 时 必须 使 用 requests 属 性 为 
容器 定义 资源 的 确保 可 用 量 。 


集群 中 的 每 个 节点 都 拥有 定量 的 CPU 和 内 存 资源 ， 调 度 Pod 时 ， 仅 
那些 被 请 求 资源 的 余 量 可 容纳 当前 被 调度 的 Pod 的 请 求 量 的 节点 才 可 作 
为 目标 节点 。 也 束 是 说 ，Kubernetes 的 调度 器 会 根据 容器 的 requests 属 性 
中 定义 的 资源 需求 量 来 判定 仪 哪些 节点 可 接收 运行 相关 的 Pod 资 源 ， 而 
对 于 一 个 节点 的 资源 来 说 ， 每 运行 一 个 Pod 对 象 ， 其 requests 中 定义 的 请 
求 量 都 要 被 预 留 ， 直 到 被 所 有 Pod 对 象 瓜分 完毕 为 止 。 

















4.8.2 ”资源 限制 


容器 的 资源 需求 仅 能 达到 为 其 保证 可 用 的 最 少 资源 量 的 目的 ， 它 并 
不 会 限制 容 费 的 可 用 资源 上 限 ， 因 此 对 因应 用 程序 自身 存在 Bug 等 多 种 
原因 而 导致 的 系统 资源 被 长 时 间 喇 用 的 情况 则 无 计 可 施 ， 这 就 需要 通过 
limits 属 性 为 容 如 定义 资源 的 最 大 可 用 量 。 资 源 分 配 时 ， 可 压缩 型 资源 
CPU 的 控制 阀 可 目 由 调节 ， 容 需 进 程 无 法 获得 超出 其 CPU 配额 的 可 用 时 
间 。 不 过 ， 如 果 进 程 申请 分 配 超出 其 limits 属 性 定义 的 硬 限制 的 内 存 资 
源 时 ， 它 将 被 OOM killer 杀 死 ， 不 过 ， 随 后 可 能 会 被 其 控制 进程 所 重 
局 ， 例 如 ， 容 器 进程 的 Pod 对 象 会 被 杀 死 并 重 局 《〈 重 月 策略 为 Always 或 
OnFailure 时 ) ， 或 者 是 容器 进程 的 子 进程 被 其 父 进程 所 重 司 。 


下 面 的 配置 清单 文件 (memleak-pod.yaml) 中 定义 了 如 何 使 用 
saadali/simmemleak 镜 像 运 行 一 个 Pod 对 象 ， 它 模拟 内 存 泄漏 操作 不 断 地 
申请 使 用 内 存 资源 ， 直 到 超出 limits 属 性 中 memory 字 段 设 定 的 值 而 导 
致 .OOMKillled” 为 I 上: 





apiVersion: v1 
kind: Pod 
metadata: 

name: memleak-pod 

labels: 
app: memleak 

spec: 

containers: 

- name: simmemleak 
image: saadali/simmemleak 
resources: 

requests: 
memory: "64Mi" 
cpu: ba 
limits: 
memory: "64Mi" 
cpu: i 





下 面 测试 其 运行 效果 ， 首 先 将 配置 清单 中 定义 的 资源 复 用 下 面 的 命 
令 创建 于 集群 中 : 








~]$ kubect1 apply -f memleak-pod.yaml 
pod/memleak created 





Pod 资 源 的 默认 重启 策略 为 Always， 于 是 在 memleak 因 内 存 资源 达 
到 硬 限 制 而 被 终止 后 会 立即 重启 ， 因 此 用 户 很 难 观察 到 其 因 OOM 而 被 
杀 死 的 相关 信息 。 不 过 ， 多 次 重复 地 因为 内 存 资源 耗 尽 而 重启 会 触发 
Kubernetes 系 统 的 重 司 延迟 机 制 ， 即 每 次 重 局 的 时 间 间 陋 会 不 断 地 拉 
长 。 于 是 ， 用 户 看 到 的 Pod 资 源 的 相关 状态 通常 
为 “CrashLoopBackOff”: 





~]$ kubectl get pods -1 app=memleak 
NAME READY STATUS RESTARTS AGE 
memleak-pod 0/1 CrashLoopBackoff 1 24S 








Pod 资 源 首 次 的 重启 将 在 crash 后 立即 完成 ， 若 随后 再 次 crash， 那 么 
其 重启 操作 会 延迟 10 秒 进行 ， 随 后 的 延迟 时 长 会 逐渐 增加 ， 依 次 为 20 
秒 、40 秒 、80 秒 、160 秒 和 300 秒 ， 随 后 的 延迟 将 固定 在 5 分 钟 的 时 长 之 
上 而 不 再 增加 ， 直 到 其 不 再 crash 或 者 delete 为 止 。describe 命 令 可 以 显示 
其 状态 相关 的 详细 信息 ， 其 部 分 内 容 如 下 所 示 : 





~]$ kubectl1 describe pods memleak-pod 


Name : memleak-pod 
Last State: Terminated 
Reason: OOMKilled 
Exit Code: 137 
Started: Wed, 02 May 2018 12:42:50 +0800 
Finished: Wed, 02 May 2018 12:42:50 +0800 
Ready: False 


Restart Count: 3 





如 上 述 命令 结果 所 显示 的 ，OOMKilled 表 示 容 器 因 内 存 耗 尽 而 被 终 
止 ， 因 此 ， 为 limits 属 性 中 的 memory 设 置 一 个 合理 值 至 关 重 要 。 与 
requests 不 同 的 是 ，limits 并 不 会 影响 Pod 的 调度 结果 ， 也 就 是 说 ， 一 个 节 
点 上 的 所 有 Pod 对 象 的 limits 数 量 之 和 可 以 大 于 节点 所 拥有 的 资源 量 ， 即 
支持 资源 的 过 载 使 用 (overcommitted) 。 不 过 ， 这 么 一 来 一 旦 资源 耗 
尽 ， 尤 其 是 内 存 资 源 耗 尽 ， 则 必然 会 有 容器 因 OOMKilled 而 终止 。 


另外 需要 说 明 的 是 ，Kubernetes 仅 会 确保 Pod 能 够 获得 它们 请 求 
(requests) 的 CPU 时 间 人 额度， 它们 能 人 否 获得 额外 〈throttled) 的 CPU 时 
间 ， 则 取决 于 其 他 正在 运行 的 作业 对 CPU 资源 的 占用 情况 。 例 如 ， 对 于 
总 数 为 1000m 的 CPU 资源 来 说 ， 容 器 A 请 求 使 用 200m， 容 器 B 请 求 使 用 











500m， 在 不 超出 它们 各 自 的 最 大 限额 的 前 提 下 ， 余 下 的 300m 在 双方 都 
需要 时 会 以 2: 5 (200m: 500m) 的 方式 进行 配置 。 


4.8.3 ”容器 的 可 见 资源 


细心 的 读者 可 能 已 经 发 现 了 这 一 点 : 于 容器 中 运行 top 等 命令 观察 
资源 可 用 量 信息 时 ， 即 便 定义 了 requests 和 ]imits 属 性 ， 虽 然 其 可 用 资源 
受 限于 此 两 个 属性 中 的 定义 ， 但 容器 中 可 见 的 资源 量 依然 是 节点 级 别 的 
可 用 总 量 。 例 如 ， 为 前 面 定 义 的 stress-pod 添 加 如 下 limits 属 性 定义 : 











limits: 
memory: "512Mi" 
cpu: "400m" 





重新 创建 stress-pod 对 象 ， 并 于 其 容器 内 分 别 列 出 容器 可 见 的 内 存 和 
CPU 资 源 总 量 ， 命 令 及 结果 如 下 所 示 : 





~]$ kubect1 exec stress-pod -- cat /proc/meminfo | grep ^MemTotal 
MemTotal: 16416472 KkB 
$ kubect1 exec stress-pod -- cat /proc/cpuinfo | grep -c ^processor 


8 





命令 结果 中 显示 其 可 用 内 存 资源 总 量 为 16416472KB (16GB) ， 
CPU 核 心 数 为 8 个 ， 这 是 节点 级 的 资源 数量 ， 而 非 由 容器 的 limits 所 定义 
的 512Mi 和 400m。 其 实 ， 这 种 结果 不 仅仅 使 得 其 得 看 命令 的 显示 结 末 看 
起 来 有 些 奇怪 ， 而 且 对 有 些 容器 应 用 的 配置 也 会 带 来 不 小 的 负面 影响 。 


较为 典型 的 是 在 Pod 中 运行 Java 应 用 程序 时 ， 若 未 使 用 “-Xmx” 选 项 
指定 JVM 的 堆 内 存 可 用 总 量 ， 它 默认 会 设置 为 主机 内 存 总 量 的 一 个 空间 
比例 (如 30%) ， 这 会 导致 容器 中 的 应 用 程序 申请 内 存 资源 时 将 会 达到 
上 限 而 转 为 OOMKilled。 男 外 ， 即 便 使 用 了 “-Xmx” 选 项 设置 其 堆 内 存 上 
限 ， 但 它 对 于 非 堆 内 存 的 可 用 空间 不 会 产生 任何 限制 作用 ， 结 果 是 仍然 
存在 达到 容器 内 存 资 源 上 限 的 可 能 性 。 


另 一 个 颇具 代表 性 的 场景 是 于 Pod 中 运行 的 nginx 应 用 ， 在 配置 参数 
worker_processes 的 值 为 "auto” 时 ， 主 进程 会 创建 与 Pod 中 能 够 访问 到 的 
CPU 核心 数 相 同 数量 的 worker 进 程 。 和 若 Pod 的 实际 可 用 CPU 核心 远 低 于 
主机 级 别 的 数量 时 ， 那 么 这 种 设置 在 较 大 的 并 发 访问 负 硬 下 会 寻 致 严重 
的 资源 竞争 ， 并 将 带 来 更 多 的 内 存 资源 消耗 。 一 个 较为 妥当 的 解决 方案 











是 使 用 Downward API 将 limits 定 义 的 资源 量 暴 器 给 容器 ， 这 一 点 将 在 后 
面 的 章节 中 予以 介绍 。 


4.8.4 Pod 的 服务 质量 类 别 


前 面 曾 提 到 过 ，Kubernetes 人 允许 节点 资源 对 limits 的 过 载 使 用 ， 这 意 
味 着 节点 无 法 同时 满足 其 上 的 所 有 Pod 对 象 以 资源 满载 的 方式 运行 。 于 
是 ， 在 内 存 资源 紧缺 时 ， 应 该 以 何 种 次 序 先后 终止 哪些 Pod 对 象 ? 
Kubernetes 无 法 自行 对 此 做 出 决策 ， 它 需要 借助 于 Pod 对 象 的 优先 级 完成 
判定 。 根 据 Pod 对 象 的 requests 和 1limits 属 性 ，Kubernetes 将 Pod 对 象 归 类 
到 BestEffort、Burstable 和 Guaranteed 三 个 服务 质量 〈Quality of Service， 
QoS) 类 别 下 ， 具 体 说 明 如 下 。 


Guaranteed: 每 个 容器 都 为 CPU 资源 设置 了 具有 相同 值 的 requests 和 
limits 属 性 ， 以 及 每 个 容 右 都 为 内 存 资源 设置 了 具有 相同 值 的 requests 和 
limits 属 性 的 Pod 资 源 会 自动 归属 于 此 类 别 ， 这 类 Pod 资 源 具 有 最 高 优先 
级 。 


.Burstable: 至 少 有 一 个 容器 设置 了 CPU 或 内 存 资 源 的 requests 属 
性 ， 但 不 满足 Guaranteed 类 别 要 求 的 Pod 资 源 将 自动 归属 于 此 类 别 ， 它 们 
具有 中 等 优先 级 。 


BestEffort: 未 为 任何 一 个 容器 设置 requests 或 limits 属 性 的 Pod 资 源 
将 目 动 归属 于 此 类 别 ， 它 们 的 优先 级 为 最 低级 别 。 


内 存 资源 紧缺 时 ，BestEffort 类 别 的 容器 将 首当其冲 地 被 终止 ， 因 为 
系统 不 为 其 提供 任何 级 别 的 资源 保证 ， 但 换 来 的 好 处 是 ， 它 们 能 够 在 可 
用 时 做 到 尽 可 能 多 地 占用 资源 。 若 已 然 不 存 任 何 BestEffort 类 别 的 容器 ， 
则 接 下 来 是 有 着 中 等 优先 级 的 Burstable 类 别 的 Pod 被 终止 。Guaranteed 类 
别 的 容器 拥有 最 高 优先 级 ， 它 们 不 会 被 杀 死 ， 除 非 其 内 存 资源 需求 超 
限 ， 或 者 OOM 时 没有 其 他 更 低 优先 级 的 Pod 资 源 存在 。 


每 个 运行 状态 容器 都 有 其 OOM 得 分 ， 得 分 越 高 越 会 被 优先 杀 死 。 
OOM 得 分 主要 根据 两 个 纬度 进行 计算 : 由 QoS 类 别 继承 而 来 的 默认 分 值 
和 容 堪 的 可 用 内 存 资源 比例 。 同 等 类 别 的 Pod 资 源 的 默认 分 值 相 同 ， 下 
面 的 代码 片段 取 自 pkg/kubelet/qos/policy.go 源 人 码 文件 ， 它 们 定义 的 是 各 
种 类 别 的 Pod 资 源 的 OOM 调 节 (Adjust) 分 值 ， 即 默认 分 值 。 其 中 ， 
Guaranteed 类 别 的 Pod 资 源 的 Adjust 分 值 为 -998， 而 BestEffort 类 别 的 默认 
分 值 为 1000，Burstable 类 别 的 Pod 资 源 的 Adjust 分 值 则 经 由 相应 的 算法 计 




















const ( 
PodInfraOOMAdj int = -998 
KubeletOOMScoreAdj int = -999 
DockerOOMScoreAdj int = -999 
KubeProxyOOMScoreAd] int = -999 
guaranteedOoOMScoreAdj int = -998 


besteffortOOMScoreAdj int = 1000 





因此 ， 同 等 级 别 优先 级 的 Pod 资 源 在 OOM 时 ， 与 自身 的 reqdquests 属 性 
相 比 ， 其 内 存 占 用 比例 最 大 的 Pod 对 象 将 被 首先 杀 死 。 例 如 ， 图 4-13 中 
的 同属 于 Burstable 类 别 的 Pod A 将 先 于 Pod B 被 杀 死 ， 虽 然 其 内 存 用 量 
小 ， 但 与 自身 的 requests 值 相 比 ， 它 的 占用 比例 95% 要 大 于 Pod B 的 
80%。 


需要 特别 说 明 的 是 ，OOM 是 内 存 耗 尽 时 的 处 理 机 制 ， 它 们 与 可 压 
缩 型 资源 CPU 无 关 ， 因 此 CPU 资源 的 需求 无 法 得 到 保证 时 ，Pod 仅 仪 是 
暂时 获取 不 到 相应 的 资源 而 已 。 














Pod A Pod B 











95% used 
Requests 
Limits 
80% used 
Requests 


图 4-13 ”资源 需求 、 资 源 限额 及 OOM 


4.9 ”本 章 小 结 


本 章 介 绍 了 Pod 资 源 的 基础 概念 、 分 布 式 系统 的 设计 模式 、Pod 的 基 
础 管理 操作 、 如 何 定 义 和 管 理 容 器 、 资 源 标 签 和 标签 选择 器 、 资 源 注 解 
等 ， 详 细 讲 解 了 Pod 生 命 周 期 中 的 事件 、 容 器 的 存活 性 探测 和 就 绪 性 探 
测 机 制 等 话题 。 


:Pod 就 是 联系 紧密 的 一 组 容器 ， 它 们 共享 Network、UTS 和 IPC 名 称 
空间 及 存储 卷 资源 。 

分布 式 系 统 设计 主要 有 Sidecar、Ambassador 和 Adapter 三 种 主要 模 
了 


:Kubermnetes 资 源 对 象 的 管理 操作 基本 上 是 由 增 、 删 、 改 和 碍 等 操作 
党 理 万 式 。 





Pod 的 核心 目标 在 于 运行 容器 ， 容 右 的 定制 配置 常见 的 包括 其 露 站 
口 及 传递 环境 变量 等 。 

标签 是 附加 在 Kubernetes 系 统 上 的 键 值 类 型 的 元 数据 ， 而 标签 选择 
器 是 基本 等 值 或 集合 关系 的 标签 过 滤 机 制 ; 注解 类 似 于 标签 ， 但 不 能 被 
用 于 标签 选择 器 。 


， ee 但 运行 主 容器 是 其 核 
心 任务 。 


存活 性 探测 及 就 绪 性 探测 是 辅助 判定 容器 状态 的 重要 工具 。 
资源 需求 及 资源 限制 是 管理 Pod 对 象 系统 资源 分 配 的 有 效 方式 。 
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目 主 式 Pod 对 象 由 调度 器 绑 定 至 目标 工作 节点 后 即 由 相应 节点 上 的 
kubelet 人 负责 监控 其 容器 的 存活 性 ， 容 器 主 进 程 朋 尝 后 ，kubelet 能 够 目 动 
重启 相应 的 容器 。 不 过 ，kubelet 对 非 主 进程 朋 尝 类 的 容器 错误 却 无 从 感 
知 ， 这 依赖 于 用 户 为 Pod 资 源 对 象 目 定义 的 存活 性 探测 (iveness 
probe 〉 机制 ， 以 便 kubelet 能 够 探知 到 此 类 故障 。 然 而 ， 在 Pod 对 象 草 到 
意外 删除 ， 或 者 工作 节点 目 喘 发 生 故 障 时 ， 又 该 如 何 处 理 昵 ? 


kubelet 是 Kubernetes 集 群 节点 代理 程序 ， 它 在 每 个 工作 节点 上 都 运 
行 着 一 个 实例 。 因 而 ， 集 群 中 的 某 工 作 节点 发 生 故 障 时 ， 其 kubelet 也 必 
将 不 再 可 用 ， 于 是 ， 节 点 上 的 Pod 资 源 的 健康 状态 将 无 从 得 到 保证 ， 也 
无 法 再 由 kubelet 重 启 。 此 种 场景 中 的 Pod 存 活性 一 般 要 由 工作 节点 之 外 
We 事实 上 ， 遭 到 意外 删除 的 Pod 资 源 的 恢复 也 依赖 于 
其 控制 器 。 


Pod 控 制 器 由 master 的 kube-controller-manager 组 件 提供 ， 常 见 的 此 类 
控制 器 有 ReplicationController、ReplicaSet、Deployment、DaemonSet、 
StatefulSet、Job 和 CronJob 等 ， 它 们 分 别 以 不 同 的 方式 管理 Pod 资 源 对 
象 。 实 践 中 ， 对 Pod 对 象 的 管理 通 向 都 是 由 茶 种 控制 器 的 特定 对 象 来 实 
现 的 ， 包 括 其 创建 、 删 除 及 重新 调度 等 操作 。 本 章 将 逐一 讲解 音 用 的 
Pod 控 制 器 资源 。 






































5.1 关于 Pod 控 制 器 


我 们 可 以 把 API Server 类 比 成 一 个 存储 对 象 的 数据 库 系 统 ， 它 同 客 
户 端 提 供 了 API， 并 负责 存储 由 用 户 创 建 的 各 种 资源 对 象 ， 至 于 各 对 象 
的 当前 状态 如 何 才能 符合 用 户 期 望 的 状态 ， 则 需要 交 由 另 一 类 称 为 控制 
器 的 组 件 来 负责 完成 。Kubernetes 提 供 了 众多 的 控制 器 来 管理 各 种 类 型 
的 资源 ， 如 Node Lifecycle Controller、Namespace Controller、Service 
Controller 和 Deployment Controller 等 ， 它 们 的 功用 几乎 可 以 做 到 见 名 知 
义 。 创 建 完 成 后 ， 每 一 个 控制 器 对 象 都 可 以 通过 内 部 的 和 解 循环 

(reconciliation loop) ， 不 间断 地 监控 着 由 其 负责 的 所 有 资源 并 确保 其 
处 于 或 不 断 地 逼近 用 户 定义 的 目标 状态 。 


尽管 能 够 由 kubelet 为 其 提供 自 印 能力 ， 但 在 市 点 宕 机 时 ， 自 主 式 
Pod 对 象 的 重建 式 自 愈 机 制 则 需要 由 Pod 控 制 器 对 象 负责 提供 ， 并 且 由 它 
来 负责 实现 生命 周期 中 的 各 类 目 动 管理 行为 ， 如 创建 及 删除 等 。 








5.1.1 Pod 控制 器 概述 


Master 的 各 组 件 中 ，API Server 仅 负责 将 资源 存储 于 etcd 中 ， 并 将 其 
变动 通知 给 各 相关 的 客户 端 程序 ， 如 kubelet、kube-scheduler、kube- 
proxy 和 kube-controller-manager 等 ，kube-scheduler 监 控 到 处 于 未 绑 定 状 
态 的 Pod 对 象 出 现时 遂 启 动 调 度 器 为 其 挑选 适 配 的 工作 节点 ， 然 而 ， 
Kubernetes 的 核心 功能 之 一 还 在 于 要 确保 各 资源 对 象 的 当前 状态 

Cstatus) 以 匹配 用 户 期 望 的 状态 〈spec) ， 使 当前 状态 不 断 地 向 期 望 状 
态 “ 和 人 解 ”(reconciliation〉 来 完成 容器 应 用 管理 ， 而 这 些 则 是 kube- 
controller-manager 的 任务 。kube-controller-manager 是 一 个 独立 的 单 体 守 
护 进程 ， 然 而 它 包 含 了 众多 功能 不 同 的 控制 器 类 型 分 别 用 于 各 类 和 人 解 任 
务 ， 如 图 5-1 所 示 。 




















Controller-Manager 


Node Controllers 
DaemonSet Controllers 
> I StatefulSet Controllers 


Node X 


Deployment Controllers 
myapp-deploy 





watches 硕 
kubelet 





图 5-1 kube-controller-manager 及 其 控制 器 








@ 提示 “Kubernetes 可 用 的 控制 器 有 attachdetach、 
bootstrapsigner、clusterrole-aggregation、 cronjob、 csrapproving、 
csrcleaner、csrsigning、daemonset、deployment、disruption、endpoint、 
garbagecollector、horizontalpodautoscaling、job、namespace、node、 
persistentvolume-binder 、persistentvolume-expander、podgc、pvc- 
protection、replicaset、replication- controller、resourcequota、Troute、 
service、serviceaccount、serviceaccount-token、 statefulset、tokencleaner 


和 了 tl 等 数 十 种 。 


创建 为 具体 的 控制 器 对 象 之 后 ， 每 个 控制 右 均 通过 API Server 提 供 
的 接口 持续 监控 相关 资源 对 象 的 当前 状态 ， 并 在 因 故 障 、 更 新 或 其 他 原 
因 导 致 系统 状态 发 生变 化 时 ， 尝 试 让 资源 的 当前 状态 向 期 望 状态 迁移 和 
逼近 。 简 单 来 说 ， 每 个 控制 器 对 象 运 行 一 个 和 解 循 环 负责 状态 和 解 ， 并 
将 目标 资源 对 象 的 当前 状态 写 入 到 其 status 字 段 中 。 控 制 器 的 “和 和解 ”循环 
如 图 5-2 所 示 。 
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图 5-2 ”控制 器 的 “和 解 ”循环 


List-Watch 是 Kubernetes 实 现 的 核心 机 制 之 一 ， 在 资源 对 象 的 状态 发 
生变 动 时 ， 由 API Server 负 责 写 入 etcd 并 通过 水 平 触发 (level-triggered) 
机 制 主动 通知 给 相关 的 客户 端 程序 以 确保 其 不 会 错过 任何 一 个 事件 。 控 
制 器 通过 API Server 的 watch 接 口 实时 监控 目标 资源 对 象 的 变动 并 执行 和 
解 操 作 ， 但 并 不 会 与 其 他 控制 器 进行 任何 交互 ， 甚 至 彼此 之 间 根 本 就 意 
识 不 到 对 方 的 存在 。 


工作 负载 (workload) 一 类 的 控制 器 资源 类 型 包括 
ReplicationController、 ReplicaSet、Deployment、DaemonSet、 
StatefulSet、Job 和 CronJob 等 ， 它 们 分 别 代表 了 一 种 类 型 的 Pod 控 制 右 资 
源 ， 各 类 型 的 功用 在 3.1.1 节 中 已 经 给 出 过 说 明 。 本 章 后 面 的 篇 幅 主要 介 
绍 各 控制 器 的 特性 及 其 应 用 ， 不 过 StatefulSet 控 制 器 依赖 于 存储 卷 资 
源 ， 因 此 它 将 单独 在 存储 卷 之 后 的 章节 中 给 予 介绍 。 

















5.1.2 ”控制 器 与 Pod 对 象 


“Pod 控制 咒 资 源 通 过 持续 性 地 监控 集群 中 运行 着 的 Pod 资 源 对 象 来 确 
保 受 其 管控 的 资源 严格 符合 用 户 期 望 的 状态 ， 例 如 资源 副本 的 数量 要 精 
确 符合 期 望 等 。 通 币 ， 一 个 Pod 控 制 器 资源 至 少 应 该 包含 三 个 基本 的 组 
成 部 分 。 


-标签 选择 器 : 匹配 并 关联 Pod 资 源 对 象 ， 并 据 此 完成 受 其 管控 的 
Pod 资 源 计数 。 


:期望 的 副本 数 ， 期望 在 集群 中 精确 运行 着 的 Pod 资 源 的 对 象 数量 。 
:Pod 模板 : 用 于 新 建 Pod 资 源 对 象 的 Pod 模 板 资 源 。 








© 注意 ”DaemonSet 用 于 确保 集群 中 的 每 个 工作 节点 或 符合 条 
件 的 每 个 节点 上 都 运行 着 一 个 Pod 副 本 ， 而 不 是 某 个 精确 的 数量 值 ， 
此 不 具有 上 面 组 成 部 分 中 的 第 二 项 。 


例如 ， 一 个 如 图 5-3 所 示 的 Deployment 控 制 器 资源 使 用 的 标签 选择 
器 为 “role=be-eshop”， 它 期 望 相关 的 Pod 资 源 副 本 数量 精确 为 3 个 ， 少 于 
此 数量 的 缺失 部 分 将 由 控制 器 通过 Pod 模 板 予 以 创建 ， 而 多 出 的 副本 也 
将 由 控制 器 负责 终止 及 删除 。 


Master | Nodes 
kube-controller-manager 


Deployment Controller | 
| Pod role:be-eshop 


eshop-deploy replicas:3 二 | Pod role:be-eshop 











label | matchLables: 
| selector role:be-eshop 








~ Pod role:be-eshop 





图 5-3 ”Deployment 控 制 器 示例 


5.1.3” Pod 模板 资源 


PodTemplate 是 Kubernetes API 的 常用 资源 类 型 ， 和 常用 于 为 控制 占 指 
定 上 自动 创建 Pod 资 源 对 象 时 所 需 的 配置 信息 。 因 为 要 内 般 于 控制 器 中 使 
用 ， 所 以 Pod 模 板 的 配置 信息 中 不 需要 apiVersion 和 kind 字 段 ， 但 除 此 之 
外 的 其 他 内 容 与 定义 自主 式 Pod 对 象 所 文 持 的 字段 几乎 完全 相同 ， 这 人 包 
括 metadata 和 spec 及 其 内 租 的 其 他 各 个 字段 。Pod 控 制 器 类 资源 的 spec 字 
段 通常 都 要 内 髓 replicas、selector 和 template 字 段 ， 其 中 template 即 为 Pod 
模板 的 定义 。 下 面 是 一 个 定义 在 ReplicaSet 资 源 中 的 模板 资源 示例 : 

















apiVersion: apps/v1 
kind: ReplicaSet 
metadata: 
name: rs-example 
spec: 
replicas: 2 
selector: 
matchLabels: 
app: rs-demo 
template: 
metadata: 
labels: 
app: rs-demo 
spec: 
Containers : 
- name: myapp 
image: ikubernetes/myapp:vi 
ports: 
- name: http 
containerPort: 80 





如 上 示例 中 ，spec.template 字 段 在 定义 时 仅 给 出 了 metadata 和 spec 两 
个 字段 ， 它 的 使 用 方法 与 自主 式 Pod 资 源 完 全 相同 。 后 面 讲 到 控制 器 的 
章节 时 会 反复 用 到 Pod 模 板 资源 。 











5.2 ”ReplicaSet 控 制 器 


Kubernetes 较 早期 的 版 本 中 仪 有 ReplicationController 一 种 类 型 的 Pod 
控制 占 ， 后 来 的 版 本 中 陆续 引入 了 更 多 的 控制 絮 实 现 ， 这 其 中 束 包 括 用 
来 取代 ReplicationController 的 新 一 代 实 现 ReplicaSet。 事 实 上 ， 除 了 额外 
文 持 基于 集合 〈set-based) 的 标签 选择 器 ， 以 及 它 的 滚动 更 新 〈Rolling- 
Update) 机 制 要 基于 更 高 级 的 控制 Deployment 实 现 之 外 ， 目 前 的 
ReplicaSet 的 其 余 功能 基本 上 与 ReplicationController 相 同 。 考 虑 到 
Kubernetes 强 烈 推 荐 使 用 ReplicaSet 控 制 器 ， 且 表示 ReplicationController 
不 久 后 即将 废弃 ， 这 里 就 重点 介绍 ReplicaSet 控 制 占 。 


5.2.1 ”ReplicaSet 概 述 


ReplicaSet《〈 简 称 RS) 古 Pod 控 制 器 类 型 的 一 种 实现 ， 用 于 确保 由 其 
管控 的 Pod 对 象 副本 数 在 任 一 时 刻 都 能 精确 满足 期 望 的 数量 。 如 图 5-4 所 
示 ，ReplicaSet 控 制品 资源 启动 后 会 查找 集群 中 匹配 其 标签 选择 器 的 Pod 
资源 对 象 ， 当 前 活动 对 象 的 数量 与 期 望 的 数量 不 吻合 时 ， 多 则 删除 ， 少 
等 Pod 资 源 副 本 数量 符合 期 望 值 后 即 进 入 下 
一 轮 和 解 循 环 。 
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图 5-4 ”ReplicaSet 的 控制 循环 (图 片 来 源 : 《Kubernetes in action》) 
ReplicaSet 的 副本 数量 、 标 签 选 择 器 甚至 是 Pod 模 板 都 可 以 随时 按 需 





进行 修改 ， 不 过 仅 改 动 期 望 的 副本 数量 会 对 现存 的 Pod 副 本 产生 直接 影 
啊 。 修 改 标签 选择 如 可 能 会 使 得 现 有 的 Pod 副 本 的 标签 变 得 不 再 匹配 ， 

此 时 ReplicaSet 控 制 器 要 做 的 不 过 是 不 再 计 入 它们 而 已 。 力 外 ， 在 创建 
完成 后 ，ReplicaSet 也 不 会 再 关注 Pod 对 象 中 的 实际 内 容 ， 因 此 Pod 模 板 


的 改动 也 只 会 对 后 来 新 建 的 Pod 副 本 产生 影 啊 。 
相 比 较 于 手动 创建 和 管理 Pod 资 源 来 说 ，ReplicaSet 能 够 实现 以 下 功 


会 忆 
月 上。 


-确保 Pod 资 源 对 象 的 数量 精确 反映 期 望 值 : ReplicaSet 需 要 确保 由 
其 控制 运行 的 Pod 副 本 数量 精确 吻合 配置 中 定义 的 期 望 值 ， 人 否则 就 会 目 
动 补 足 所 缺 或 终止 所 余 。 


确保 Pod 健 康 运行 : 探 负 到 由 其 管控 的 Pod 对 象 因 其 所 在 的 工作 节 
人 目 动 请 求 由 调度 占 于 其 他 工作 节点 创建 缺失 的 Pod 
一 本。 


:弹性 伸缩 : 业务 规模 因 各 种 原因 时 和 常 存在 明显 波动 ， 在 波峰 或 波 
谷 期 间 ， 可 以 通过 ReplicaSet 控 制 右 动态 调整 相关 Pod 资 源 对 象 的 数量 。 
此 外 ， 在 必要 时 还 可 以 通过 HPA (HroizontalPodAutoscaler) 控制 器 实现 
Pod 资 源 规模 的 目 动 伸缩 。 





5.2.2 ”创建 ReplicaSet 


类 似 于 Pod 资 源 ， 创 建 ReplicaSet 控 制 器 对 象 同样 可 以 使 用 YAML 或 
JSON 格 式 的 清单 文件 定义 其 配置 ， 而 后 使 用 相关 的 创建 命令 来 完成 资 
源 创建 。 前 面 5.1.3 节 中 给 出 的 示例 清单 就 是 一 个 简单 的 ReplicaSet 的 定 
义 。 它 也 由 kind、apiVersion、metadata、spec 和 status 这 5 个 一 级 字段 组 
成 ， 其 中 status 为 只 读 字段 ， 因 此 需要 在 清单 文件 中 配置 的 仅 为 前 4 个 字 
段 。 它 的 spec 字 上段 一 般 藤 套 使 用 以 下 几 个 属性 字段 。 


replicas<integer>: 期 望 的 Pod 对 象 副 本 数 。 


'Selector<Object>: 当前 控制 器 匹配 Pod 对 象 副 本 的 标签 选择 器 ， 文 
持 matchLabels 和 matchExpressions 两 种 匹配 机 制 。 


:template<Object>: 用 于 补足 Pod 副 本 数量 时 使 用 的 Pod 模 板 资源 。 

-minReadySecond<integer>s: 新 建 的 Pod 对 象 ， 在 局 动 后 的 多 长 时 
间 内 如 果 其 容器 未 发 生 崩 尝 等 异常 情况 即 被 视 为 “就 绕 ”， 默认 为 0 秒 ， 
表示 一 旦 就 绪 性 探测 成 功 ， 即 被 视 作 可 用 。 


将 5.1.3 节 中 的 示例 保存 于 资源 清单 文件 中 ， 例 如 rs-example.yaml， 
而 后 即 可 使 用 如 下 命令 将 其 创建 : 








~]$ kubect1l apply -f rs-example.yaml 
replicaset.apps "rs-example" created 








集群 中 当前 没有 标签 为 “app: rs-demo” 的 Pod 资 源 存在 ， 因 此 rs- 
example 需 要 按照 replicas 字 上 段 的 定义 创建 它们 ， 名 称 以 其 所 属 的 控制 占 
名 称 为 前 级 。 这 两 个 Pod 资 源 目前 都 处 于 ContainerCreating 状 态 ， 即 处 于 
容器 创建 过 程 中 ， 待 创建 过 程 完 成 后 ， 其 状态 即 转 为 Running，Pod 也 将 
转变 为 “READY”: 





~]# kubectl1 get pods -1 app=rs-demo 

NAME READY STATUS RESTARTS AGE 
rs-example-p66nv 0/1 ContainerCreating 0 8s 
rs-example-rdm7q 0/1 ContainerCreating 0 8s 





接 下 来 可 以 使 用 “kubectl get replicaset” 命 令 查 看 ReplicaSet 控 制 嚣 资 
源 的 相关 状态 。 下 面 的 命令 结果 显示 出 它 已 经 根据 清单 中 配置 的 Pod 模 
2 个 Pod 资 源 ， 不 过 这 时 它们 尚未 创建 完成 ， 因 此 仍 
为 “READY”: 








~]$ kubectl1 get replicaset rs-example -0 wide 
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR 
rs-example 2 2 0 2m nginx ikubernetes/myapp:v1i app=rs-demo 





经 由 控制 器 创建 与 用 户 自 主创 建 的 Pod 对 象 的 功能 并 无 二 人 至， 但 其 
自动 和 解 的 功能 在 很 大 程度 上 能 为 用 户 省 去 不 少 的 管理 精力 ， 这 也 是 使 
得 Kubernetes 系 统 之 上 的 应 用 程序 弯 得 拥有 目 您 能 力 的 主要 保障 。 


5.2.3 ReplicaSet 管 控 下 的 Pod 对 象 


5.2.2 市 中 创建 的 rc-example 通 过 标签 选择 器 将 拥有 “app=rs-demo” 标 
签 的 Pod 资 源 收 归于 磨 下 ， 并 确保 其 数量 精确 符合 所 期 望 的 数目 ， 使 用 
标签 选择 器 显示 出 的 Pod 资 源 列 表 也 能 验证 这 一 点 。 然 而 ， 实 际 中 存在 
痢 不 少 可 能 导致 Pod 对 象 数目 与 期 望 值 不 符合 的 可 能 性 ， 如 Pod 对 象 的 意 
外 删除 、Pod 对 象 标签 的 变动 (已 有 的 Pod 资 源 变 得 不 匹配 控制 器 的 标签 
选择 器 ， 或 者 外 部 的 Pod 资 源 标签 变 得 匹配 到 了 控制 器 的 标签 选择 
上 器)、 控 制 器 的 标签 选择 器 变动 ， 甚 至 是 工作 市 点 故障 等 。ReplicaSet 
0 0 0 并 及 时 启动 和 解 操 


1. 人 缺少 Pod 副 本 


任何 原因 导致 的 相关 Pod 对 象 丢 失 ， 都 会 由 ReplicaSet 控 制 左 自动 补 
足 。 例 如 ， 手 动 删 除 上 面 列 出 的 一 个 Pod 对 象 ， 命 令 如 下 : 














~]$ kubect1 delete pods rs-example-rdm7q 
pod "rs-example-rdm7q" deleted 





再 次 列 出 相关 Pod 对 象 的 信息 ， 可 以 看 到 被 删除 的 rs-example-rdm7dq 
进入 了 终止 过 程 ， 而 新 的 Pod 对 象 rs-example-l4gkp 正 在 被 rs-example 控 制 
器 创建 : 





~]$ kubect1l get pods -1 app=rs-demo -o wide 
DY 


NAME REA STATUS RESTARTS AGE 
rs-example-14gkp 0/1 ContainerCreating 0 1S 
rs-example-p66nv 1/1 Running 0 39m 


rs-example-rdm7q 0/1 Terminating 0 39m 








另外 ， 强 行 修改 隶属 于 控制 器 rs-example 的 某 Pod 资 源 ( 匹 配 于 标签 
控制 器 〉 的 标签 ， 会 号 致 它 不 再 被 控制 器 作为 副本 计数 ， 这 也 将 触发 控 
制 器 的 Pod 对 象 副本 缺失 补足 机 制 。 例 如 ， 将 rs-example-p66nv 的 标签 
app 的 值 置 空 : 





~]$ kubectl1 label pods rs-example-p66nv app= --overwrite 


pod "rs-example-p66nv" labeled 





列 出 rs-example 相 关 Pod 对 象 的 信息 ， 发 现 rs-example-p66nv 已 经 消 
失 不 见 ， 并 且 正 在 创建 新 的 对 象 副本 。 





~]$ kubect1 get pods -1 app=rs-demo 


NAME READY STATUS RESTARTS AGE 
rs-example-4bqzv 0/1 ContainerCreating 0 2S 
rs-example-14gkp 1/1 Running 0 5m 





由 此 可 见 ， 修 改 Pod 资 源 的 标签 即 可 将 其 从 控制 器 的 管控 之 下 移 
出 ， 当 然 ， 修 改 后 的 标签 如 果 义 能 被 其 他 控制 器 资源 的 标签 选择 器 所 命 
中 ， 则 此 时 它 又 成 了 隶属 于 男 一 控制 器 的 副本 。 如 果 修 改 其 标签 后 的 
Pod 对 象 不 再 隶属 于 任何 控制 器 ， 那 么 它 就 将 成 为 自主 式 Pod， 与 此 前 手 
动 直接 创建 的 Pod 对 象 的 特性 相同 ， 即 误 删除 或 所 在 的 工作 节点 故障 都 
会 造成 其 永久 性 的 消失 。 


2. 多 出 Pod 副 本 
一 旦 被 标签 选择 器 匹配 到 的 Pod 资 源 数量 因 任何 原因 超出 期 望 值 ， 


多 余 的 部 分 都 将 被 控制 器 自动 删除 。 例 如 ， 为 pod-example 手 动 为 其 添 
加 “app: rs-demo” 标 签 : 




















~]$ kubectl1 label pods pod-example app=rs-demo 
pod "pod-example" labeled 





再 次 列 出 相关 的 Pod 资 源 ， 可 以 看 到 rs-example 控 制 右 启动 了 删除 多 
余 Pod 的 操作 ，pod-example 下 处 于 终止 过 程 中 : 





~]$ kubectl1 get pods -1 app=rs-demo 


NAME READY STATUS RESTARTS AGE 
pod-example 1/1 Terminating 0 2m 

rs-example-4bqzv 1/1 Running 0 17m 
rs-example-14gkp 1/1 Running 0 22m 











这 就 意味 着 ， 任 何 目 主 式 的 或 本 隶属 于 其 他 控制 费 的 Pod 资 源 其 标 
签 变 动 的 结果 一 旦 匹配 到 了 其 他 的 副本 数 足 额 的 控制 占 ， 束 会 寻 致 这 类 
Pod 资 源 被 删除 。 





3. 查 看 Pod 资 源 变动 的 相关 事件 


“kubectl describe replicasets” 命 令 可 打印 出 ReplicaSet 控 制 器 的 详细 
状态 ， 从 下 面 命令 结果 中 Events 一 段 也 可 以 看 出 ，rs-example 执 行 了 Pod 
资源 的 创建 和 删除 操作 ， 为 的 就 是 确保 其 数量 的 精确 性 。 





~]$ kubect1 describe replicasets/rs-example 


Name : rs-example 
Namespace: default 
Selector: app=rs-demo 
Labels: app=rs-demo 
Events 


Type Reason Age ”From Message 


Normal SuccessfulCreate 21m replicaset-controller Created pod: rs- 
example-14gkp 

Normal SuccessfulDelete 4m replicaset-controller Deleted pod: pod- 
example 

Normal SuccessfulCreate 26m replicaset-controller Created pod: rs- 
example-4bqzv 





事实 上 ，ReplicaSet 控 制 器 能 对 Pod 对 象 数 目的 异常 及 时 做 出 响应 ， 
是 因为 它 向 API Server 注 册 监 听 (watch) 了 相关 资源 及 其 列表 的 变动 信 
娠 ， 于 是 API Server 会 在 变动 发 生 时 立即 通知 给 相关 的 监听 客户 端 。 


而 因 节 点 自身 故障 而 导致 的 Pod 对 象 竺 失 ，ReplicaSet 控 制 器 一 样 会 
使 用 补足 资源 的 方式 进行 处 理 ， 这 里 不 再 详细 说 明 其 过 程 。 有 兴趣 的 读 
RN 
理 过 程 。 








5.2.4 ”更 新 ReplicaSet 控 制 器 


ReplicaSet 控 制 占 的 核心 组 成 部 分 是 标签 选择 器 、 副 本 数量 及 Pod 模 
板 ， 但 更 新 操作 一 般 是 围绕 replicas 和 template 两 个 字段 值 进行 的 ， 毕 竟 
改变 标签 选择 器 的 需求 几乎 不 存在 。 改 动 Pod 模 板 的 定义 对 已 经 创建 完 
成 的 活动 对 象 无 效 ， 但 在 用 户 逐 个 手动 关闭 其 旧版 本 的 Pod 资 源 后 就 能 
以 新 代 旧 ， 实 现 控制 器 下 应 用 版 本 的 滚动 升级 。 男 外 ， 修 改 副 本 的 数量 
也 束 意 味 着 应 用 规模 的 扩展 (提升 期 望 的 副本 数量 ) 或 收缩 (降低 期 望 
的 副本 数量 ) 。 这 两 种 操作 也 是 系统 运 维 人 员 日 党 维护 工作 的 重要 组 成 


部 分 。 
1. 更 改 Pod 模 板 : 升级 应 用 


ReplicaSet 控 制 右 的 Pod 模 板 可 随时 按 需 修改 ， 但 它 仅 影 响 这 之 后 由 
其 新 建 的 Pod 对 象 ， 对 已 有 的 副本 不 会 产生 作用 。 大 多 数 情况 下 ， 用 户 
需要 改变 的 通常 是 模板 中 的 容器 镜像 文件 及 其 相关 的 配置 以 实现 应 用 的 
版 本 升级 。 下 面 的 示例 清单 文件 片断 (rs-example-v2.yaml) 中 的 内 容 与 
Crs-example.yaml) 的 唯一 不 同 之 处 也 仅 在 于 镜像 文件 的 改 
Bj: 











containers: 
- name: nginx 
image: ikubernetes/myapp:v2 
ports: 
- name: http 
containerPort: 80 


对 新 版 本 的 清单 文件 执行 “kubectl apply” 或 “kubectl replace” 命 令 即 
可 完成 rs-example 控 制 嚣 资源 的 修改 操作 : 





~]$ kubectl1 replace -f rs-example-v2.yaml 
replicaset.apps "rs-example" replaced 





不 过 ， 控 制 右 rs-example 管 控 的 现存 Pod 对 象 使 用 的 仍然 是 原来 版 本 
中 定义 的 镜像 : 





~]$ kubectl get pods -1 app=rs-demo -0o \ 


custom-columns=Name:metadata.name, Image:spec.containers[0].image 
Name Image 


rs-example-4bqzv ikubernetes/myapp:v1 
rs-example-14gkp ikubernetes/myapp:v1 





此 时 ， 手 动 删 除 控制 器 现 有 的 Pod 对 象 〈 或 修改 与 其 匹配 的 控制 器 
标签 选择 器 的 标签 ， ， 并 由 控制 器 基于 新 的 Pod 模 板 自 动 创 建 出 足 额 的 
即 可 完成 一 次 应 用 的 升级 。 新 旧 更 蔡 的 过 程 文 持 如 下 两 类 操 

有 起 


一 次 性 删除 控制 占 相 关 的 所 有 Pod 副 本 或 更 改 相关 的 标签 : 剧烈 更 


替 ， 可 能 会 导致 Pod 中 的 应 用 短 时 间 不 可 访问 〈 如 图 5-5 所 示 ) ;生产 实 
践 中 ， 此 种 做 法 不 可 取 。 
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图 5-5 ”直接 更 普 所 有 Pod 资 源 


:分 批 次 删除 旧 有 的 Pod 副 本 或 更 改 其 标签 〈 生 控制 絮 补 足 后 再 删除 
为 一 批 ) : 深 动 更 瞪 ， 更 准 期 间 新 旧版 本 共存 (如 图 5-6 所 示 )〉。 




















> 
ReplicaSet ReplicaSet ReplicaSet 
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图 5-6 ”滚动 更 蔡 


例如 ， 这 里 采用 第 一 种 方式 进行 操作 ， 一 次 性 删除 rs-example 相 天 
的 所 有 Pod 副 本 : 





~]$ kubectl1 delete pods - app=rs-demo 
pod "rs-example-4bqzv" deleted 
pod "rs-example-14gkp" deleted 





再 次 列 出 rc-example 控 制 器 相关 的 Pod 及 其 容器 镜像 版 本 时 可 以 发 
现 ， 使 用 新 版 本 镜像 的 Pod 已 经 创建 完成 : 





~]$ kubectl1 get pods -1 app=rs-demo -oO 
custom-columns=Name:metadata.name, Image:spec.containers[0].image 
Name Image 

rs-example-4bwqq ikubernetes/myapp:v2 

rs-example-hqgnh ikubernetes/myapp:v2 





必要 时 ， 用 户 还 可 以 将 Pod 模 板 改 回 旧 的 版 本 进行 应 用 的 “ 降 
级 ”或 “ 回 深 *"， 它 的 操作 过 程 与 上 述 过程 基 本 类 似 。 事 实 上 ， 修 改 Pod 模 
板 时 ， 不 仅仅 能 答 换 镜像 文件 的 版 本 ， 甚 至 还 可 以 将 其 葡 换 成 其 他 正在 
运行 着 的 、 完 全 不 同 应 用 的 镜像 ， 只 不 过 此 类 需求 并 不 多 见 。 知 同时 改 
动 的 还 有 Pod 模 板 中 的 其 他 字段 ， 那 么 在 新 旧 更 丛 的 过 程 中 ， 它 们 也 将 
随 之 被 应 用 。 


以 上 操作 只 为 说 明 应 用 部 普 的 方式 ， 实 际 使 用 时 还 需要 更 为 完善 的 
机 制 。 即 便 是 仅 执行 了 一 到 多 次 删除 操作 ， 手 动 执行 更 蔡 操 作 也 并 非 一 
项 轻松 的 任务 ， 幸 运 的 是 ， 更 高 级 别 的 Pod 控 制 器 Deployment 能 够 自动 
实现 更 完善 的 深 动 更 新 和 回 深 ， 并 为 用 户 提 供 自 定义 更 新 策略 的 接口 。 
而 且 ， 经 过 精心 组 织 的 更 新 操作 还 可 以 实现 诸如 蓝 绿 部 署 (Blue/Green 
Deployment) 、 金 丝 八 部 署 〈Canary Deployment) 和 灰 度 部 署 等 ， 这 些 
内 容 将 在 后 面 章节 中 详细 展开 说 明 。 


2. 扩 容 和 缩 容 


改动 ReplicaSet 控 制 器 对 象 配 置 中 期 望 的 Pod 副 本 数量 〈replicas 字 
段 ) 会 由 控制 器 实时 做 出 啊 应 ， 从 而 实现 应 用 规模 的 水 平 伸缩 。replicas 
的 修改 及 应 用 方式 同 Pod 模 板 ， 不 过 ，kubectl 还 提供 了 一 个 专用 的 子 命 
令 scale 用 于 实现 应 用 规模 的 伸缩 ， 它 文 持 从 资源 清单 文件 中 获取 新 的 目 
标 副 本 数量 ， 也 可 以 直接 在 命令 行 通过 “--replicas” 选 项 进行 读 取 ， 例 如 
将 rs-example 控 制 器 的 Pod 副 本 数量 提升 至 5 个 : 

















~]$ kubect1 scale replicasets rs-example --replicas=5 
replicaset.extensions "rs-example" scaled 





由 下 面 显示 的 rs-example 资 源 的 状态 可 以 看 出 ， 将 其 Pod 资 源 副 本 数 
量 扩 展 至 5 个 的 操作 已 经 成 功 完 成 : 





~]$ kubectl1 get replicasets rs-example 
NAME DESIRED CURRENT READY AGE 
rs-example 5 5 5 12h 











ee 收缩 规模 的 方式 与 扩展 相同 ， 只 需要 明确 指定 目标 副本 数量 即 可 。 
列 如 : 





~]$ kubect1 scale replicasets rs-example --replicas=3 
replicaset .extensions "rs-example" scaled 








另外 ，kubectl scale 命 令 还 支持 在 现 有 Pod 副 本 数量 符合 指定 的 值 时 
才 执 行 扩 展 操作 ， 这 仪 需 要 为 命令 使 用 “--current-replicas” 选 项 即 可 。 例 
如 ， 下 面 的 合 令 表示 如 果 rs-example 目 前 的 Pod 副 本 数量 为 2， 就 将 其 扩 - 
展 至 4 个 : 


~]$ kubect1 scale replicasets rs-example --current-replicas=2 --replicas=4 
error: Expected replicas to be 2, was 3 





但 由 于 rs-example 控 制 占 现存 的 副本 数量 是 3 个 ， 因 此 上 面 的 扩展 操 
作 未 执行 并 返回 了 错误 提示 。 








Os 如 果 ReplicaSet 控 制 右 管控 的 是 有 状态 的 应 用 ， 例 如 主 
从 架构 的 Redis 集 群 ， 那 么 上 述 这 些 升级 、 降 级 、 扩 展 和 收缩 的 操作 都 
需要 精心 编排 和 参与 才能 进行 ， 不 过 ， 这 也 在 一 定 程度 上 降低 了 
Kubernetes 容 器 编排 的 价值 和 意义 。 好 在 ， 它 提供 了 StatefulSet 资 源 来 应 
对 这 种 需求 ， 因 此 ，ReplicaSet 通 常 仅 用 于 管理 无 状态 的 应 用 ， 如 HTTP 
服务 程序 等 。 





5.2.5 删除 ReplicaSet 控 制 器 资源 


使 用 kubectl delete 命 令 删 除 ReplicaSet 对 象 时 默认 会 一 并 删除 其 管控 
的 各 Pod 对 象 。 有 时 ， 考 虑 到 这 些 Pod 资 源 未 必 由 其 创建 ， 或 者 即便 由 其 
创建 却 也 并 非 其 自身 的 组 成 部 分 ， 故 而 可 以 为 命令 使 用 “-- 
cascade=false" 选 项 ， 取 消 级 联 ， 删 除 相关 的 Pod 对 象 ， 这 在 Pod 资 源 后 续 
可 能 会 再 次 用 到 时 尤为 有 有 用。 例如， 删除 rs 控制 器 rs-example: 





~]$ kubect1 delete replicasets rs-example --cascade=false 
replicaset.extensions "rs-example" deleted 





删除 操作 完成 后 ， 此 前 由 rs-example 控 制 器 管控 的 各 Pod 对 象 仍 处 于 
活动 状态 ， 但 它们 变 成 了 自主 式 Pod 资 源 ， 用 户 需 要 自行 组 织 和 维护 好 


它们 。 


@ 提示 。 后 续 讲 到 的 各 Pod 控 制 器 的 删除 方式 都 与 ReplicaSet 类 
似 ， 这 里 就 不 再 分 别 进行 说 明了 。 





尽管 ReplicaSet 控 制 器 功能 强大 ， 但 在 实践 中 ， 它 却 并 非 是 用 户 直 
的 控制 器 ， 而 是 要 由 比 其 更 高 一 级 抽象 的 Deployment 控 制 占 对 象 
来 调用 。 


5.3 Deployment 控制 絮 

Deployment〈 简 写 为 deploy) 是 Kubernetes 控 制 器 的 又 一 种 实现 ， 
它 构建 于 ReplicaSet 控 制 器 之 上 ， 可 为 Pod 和 ReplicaSet 资 源 提供 声明 式 
更 新 。 相 比较 而 言 ，Pod 和 ReplicaSet 是 较 低 级 别 的 资源 ， 它 们 很 少 被 直 
接 使 用 。Deployment、ReplicaSet 和 Pod 的 关系 如 图 5-7 所 示 。 
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图 5-7 Deployment、ReplicaSets 和 Pods 
Deployment 控 制 器 资源 的 主要 职 贡 同样 是 为 了 保证 Pod 资 源 的 健康 
运行 ， 其 大 部 分 功能 均 可 通过 调用 ReplicaSet 控 制 右 来 实现 ， 同 时 还 增 
添 了 部 分 特性 。 


.事件 和 状态 查看 : 必要 时 可 以 查看 Deployment 对 象 升级 的 详细 进 
上 度 和 状态 。 


` 回 深 : 升级 操作 完成 后 发 现 问 题 时 ， 支 持 使 用 回 深 机 制 将 应 用 返 
回 到 前 一 个 或 由 用 户 指 定 的 历史 记录 中 的 版 本 上 。 


版 本 记录 : 对 Deployment 对 象 的 每 一 次 操作 都 子 以 保存 ， 以 供 后 
续 可 能 执行 的 回 深 操 作 使 用 。 


暂停 和 局 动 : 对 于 每 一 次 升级 ， 都 能 够 随时 暂停 和 局 动 。 


.多 种 自动 更 新 方案 : 一 是 Recreate， 即 重建 更 新 机 制 ， 全 面 停止 、 
删除 日 有 的 Pod 后 用 新 版 本 蔡 代 ; 另 一 个 是 RollingUpdate， 即 滚动 升级 











机 制 ， 逐 步 符 换 旧 有 的 Pod 至 新 的 版 本 。 


5.3.1 创建 Deployment 


Deployment 是 标准 的 Kubernetes API 资 源 ， 它 建构 于 ReplicaSet 资 源 
之 上 ， 于 是 其 spec 字 上 段 中 骸 套 使 用 的 字段 包含 了 ReplicaSet 控 制 嚣 文 持 的 
replicas、selector、template 和 minReadySeconds， 它 也 正 是 利用 这 些 信息 
完成 了 其 二 级 资源 ReplicaSet 对 象 的 创建 。 下 面 是 一 个 Deployment 控 制 
器 资源 的 配置 清单 示例 : 





apiVersion: appSs/Vv1I 
kind: Deployment 
metadata: 
name: myapp-deploy 
spec: 
replicas: 3 
selector: 
matchLabels: 
app: myapp 
template: 
metadata: 
labels: 
app: myapp 
spec: 
Containers : 
- name: myapp 
image: ikubernetes/myapp:vi 
ports: 
- containerPort: 80 
name: http 





上 面 的 内 容 显 示 出 ， 除 了 控制 占 类 型 和 名 称 之 外 ， 它 与 前 面 
ReplicaSet 控 制 器 示例 中 的 内 容 几乎 没有 什么 不 同 。 下 面 在 集群 中 创建 
以 了 解 它 的 工作 方式 : 





~]$ kubectl1 apply -f myapp-deploy.yaml --record 
deployment.apps "myapp-deploy" created 





“kubectl get deployments” 命 令 可 以 列 出 创建 的 Deployment 对 象 
myapp-deploy 及 其 相关 的 信息 。 下 面 显示 的 字段 中 ，UP-TO-DATE 表 示 
己 经 达到 期 望 状态 的 Pod 副 本 数量 ，AVAILABLE 则 表示 当前 处 于 可 用 
状态 的 应 用 程序 的 数量 : 





~]$ kubectl get deployments myapp-deploy 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
myapp-deploy 3 3 3 3 13s 





Deployment 控 制 费 会 自动 创建 相关 的 ReplicaSet 控 制 器 资源 ， 并 
以 “[DEPLOYMENT-NAME]-[POD-TEMPLATE-HASH-VYALUE]” 格 式 为 
其 命名 ， 其 中 的 hash 值 由 Deployment 控 制 器 自动 生成 。 由 Deployment 创 
建 的 ReplicaSet 对 象 会 自动 使 用 相同 的 标签 选择 上 器， 因此， 可 使 用 类 似 
如 下 的 命令 查看 其 相关 的 信息 : 





~]$ kubectl1 get replicasets -1 app=myapp 
NAME DESIRED CURRENT READY AGE 
myapp-deploy-86b4b8c75d 3 3 3 37S 





相关 的 Pod 对 象 的 信息 可 以 用 相似 的 命令 进行 获取 。 下 面 的 命令 结 
果 中 ，Pod 对 象 的 名 称 遵 循 ReplicaSet 控 制 器 的 命名 格式 ， 它 以 
ReplicaSet 控 制 器 的 名 称 为 前 经， 后 跟 5 位 随机 字符 : 





~]$ kubectl1 get pods -1 app=myapp 


NAME READY STATUS RESTARTS AGE 
myapp-deploy-86b4b8c75d-7dtxn 1/1 Running 0 46S 
myapp-deploy-86b4b8c75d-hdw9z 1/1 Running 0 46S 
myapp-deploy-86b4b8c75d-w4SsVj 1/1 Running 0 46S 





由 此 印证 了 Deployment 借 助 于 ReplicaSet 管 理 Pod 资 源 的 机 制 ， 于 是 
可 以 得 知 ， 其 大 部 分 管理 操作 与 ReplicaSet 相 同 。 不 过 ，Deployment 也 
有 ReplicaSet 所 不 具有 的 部 分 高 级 功能 ， 这 其 中 最 朝 名 的 当 数 其 自动 滚 
动 更 新 的 机 制 。 





5.3.2 ”更 新 策略 


如 前 所 述 ，ReplicaSet 控 制 器 的 应 用 更 新 需要 手动 分 成 多 步 并 以 特 
定 的 次 序 进行 ， 过 程 繁杂 且 容 易 出 错 ， 而 Deployment 却 只 需要 由 用 户 指 
定 在 Pod 模 板 中 要 改动 的 内 容 ， 例 如 容器 镜像 文件 的 版 本 ， 余 下 的 步骤 
可 交 由 其 自动 完成 。 同 样 ， 更 新 应 用 程序 的 规模 也 只 需要 修改 期 望 的 副 
本 数量 ， 余 下 的 事情 交 给 Deployment 控 制 句 即 可 。 


Deployment 控 制 器 详细 信息 中 包含 了 其 更 新 策略 的 相关 配置 信息 ， 
如 myapp-deploy 控 制 右 资源 “kubectl describe” 命 令 中 输出 的 
StrategyType、RollingUpdateStrategy 字 段 等 : 

















~]$ kubect1 describe deployments myapp-deploy 


Name : myapp-deploy 

Namespace: default 

CreationTimestamp: Fri, 02 Mar 2018 09:57:06 +0800 

Labels: app=deploy-demo 

Annotations : deployment .kubernetes.io/revision=1 

Selector: app=myapp 

Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailab] 
StrategyType: RollingUpdate 

MinReadySeconds : 0 


RollingUpdateStrategy: 25% max unavailable, 25% max Surge 
OldReplicaSets: <none> 
NewReplicaSet: myapp-deploy-86b4b8c75d (3/3 replicas created) 





Deployment 控 制 絮 支持 两 种 更 新 策略 : 滚动 更 新 (rolling update) 
和 重新 创建 (recreate)， 默 认为 深 动 更 新 。 重 新 创建 更 新 类 似 于 前 文中 
ReplicaSet 的 第 一 种 更 新 方式 ， 即 首先 删除 现 有 的 Pod 对 象 ， 而 后 由 控制 
器 基于 新 模板 重新 创建 出 新 版 本 资源 对 象 。 通 常 ， 只 应 该 在 应 用 的 新 旧 
版 本 不 兼容 (如 依赖 的 后 站 数据 库 的 schema 不 同 且 无 法 兼容 ) 时 运行 时 
才 会 使 用 recreate 策 略 ， 因 为 它 会 导致 应 用 符 换 期 间 和 暂时 不 可 用 ， 好 处 在 
ee 用 户 访问 到 的 要 么 是 应 用 的 新 版 本 ， 要 么 是 旧版 





滚动 升级 是 默认 的 更 新 策略 ， 它 在 删除 一 部 分 旧版 本 Pod 资 源 的 同 
时 ， 补 充 创 建 一 部 分 新 版 本 的 Pod 对 象 进行 应 用 升级 ， 其 优势 是 升级 期 
间 ， 容 器 中 应 用 提供 的 服务 不 会 中 断 ， 但 要 求 应 用 程序 能 够 应 对 新 旧版 


本 同时 工作 的 情形 ， 例 如 新 旧版 本 兼容 同一 个 数据 库 方案 等 。 不 过 ， 更 
新 操作 期 间 ， 不 同 客户 端 得 到 的 啊 应 内 容 可 能 会 来 自 不 同 版 本 的 应 用 。 


Deployment 控 制 器 的 滚动 更 新 操作 并 非 在 同一 个 ReplicaSet 控 制 器 
对 象 下 删除 并 创建 Pod 资 源 ， 而 是 将 它们 分 置 于 两 个 不 同 的 控制 器 之 
下 : 旧 控 制 器 的 Pod 对 象 数 量 不 断 减少 的 同时 ， 新 控制 器 的 Pod 对 象 数 量 
不 断 增 加 ， 直 到 旧 控 制 器 不 再 拥有 Pod 对 象 ， 而 新 控制 器 的 副本 数量 变 
得 完全 符合 期 望 值 为 止 ， 如 图 5-8 所 示 。 
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图 5-8 Deployment 的 滚动 更 新 


滚动 更 新 时 ， 应 用 升级 期 间 还 要 确保 可 用 的 Pod 对 象 数量 不 低 于 革 
国 值 以 确保 可 以 持续 处 理 客 户 端的 服务 请 求 ， 变 动 的 方式 和 Pod 对 象 的 
数量 范围 将 通过 spec.strategy.rollingUpdate.maxSurge 和 
spec.strategy.rollingUpdate.maxUnavailable 两 个 属性 协同 进行 定义 ， 它 们 
的 功用 如 图 5-9 所 示 。 


-maxSurge: 指定 升级 期 间 存 在 的 总 Pod 对 象 数 量 最 多 可 超出 期 望 值 
的 个 数 ， 其 值 可 以 是 0 或 正 整 数 ， 也 可 以 是 一 个 期 望 值 的 百分比 ; 例 
如 ， 如 末期 望 值 为 9， 当 前 的 属性 值 为 1， 则 表示 Pod 对 象 的 总 数 不 能 超 


过 4 个 。 


-maxUnavailable: 升级 期 间 正 常 可 用 的 Pod 副 本 数 〈 包 括 新 旧版 
本 ) 最 多 不 能 低 于 期 望 数 值 的 个 数 ， 其 值 可 以 是 0 或 正 整 数 ， 也 可 以 是 
一 个 期 望 值 的 百分比 ， 默 认 值 为 1， 该 值 意 味 着 如 果 期 望 值 是 3， 则 升级 
期 间 至 少 要 有 两 个 Pod 对 象 处 于 正常 提供 服务 的 状态 。 
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图 5-9 ”maxSurge 和 maxUnavailable 的 作用 方式 (图 片 来 源 : 


《Kubernetes in action》 ) 


O 注意 ”maxSurge 和 maxUnavailable 属 性 的 值 不 可 同时 为 0， 人 否 
则 Pod 对 象 的 副本 数量 在 符合 用 户 期 望 的 数量 后 无 法 做 出 合理 变动 以 进 
行 深 动 更 新 操作 。 


配置 时 ， 用 户 还 可 以 使 用 Deplpoyment 控 制 器 的 
spec.minReadySeconds 属 性 来 控制 应 用 升级 的 速度 。 新 旧 更 人 蔡 过 程 中 ， 
新 创建 的 Pod 对 象 一 旦 成 功 啊 应 就 绪 探 测 即 被 视 作 可 用 ， 而 后 即 可 立即 
开始 下 一 轮 的 替换 操作 。 而 spec.minReadySeconds 能 够 定义 在 新 的 Pod 对 
象 创建 后 至 少 要 等 竺 多久 才 会 将 其 视 作 束 绪 ， 在 此 期 间 ， 更 新 操作 会 被 
阻塞 。 因 此 ， 它 可 以 用 来 让 Kubernetes 在 每 次 创建 出 Pod 资 源 后 都 要 等 上 
一 段 时 长 后 再 开始 下 一 轮 的 更 蔡 ， 这 个 时 间 长 度 的 理想 值 是 等 到 Pod 对 
象 中 的 应 用 已 经 可 以 接受 并 处 理 请 求 流量 。 事 实 上 ， 一 个 精心 设计 的 等 
Ba 性 探测 能 让 Kubernetes 系 统 规避 一 部 分 因 程序 Bug 而 导致 

I 升级 故障 。 


Deployment 控 制 器 也 支持 用 户 保留 其 深 动 更 新 历史 中 的 旧 
ReplicaSet 对 象 版 本 ， 如 图 5-10 所 示 ， 这 赋予 了 控制 器 进行 应 用 回 深 的 能 
力 : 用 户 可 按 需 回 深 到 指定 的 历史 版 本 。 控 制 嚣 可 保存 的 历史 版 本 数量 














由 “spec.revisionHistoryLimit” 属 性 进行 定义 。 当 然 ， 也 只 有 保存 于 
revision 历 史 中 的 ReplicaSet 版 本 可 用 于 回 深 ， 因 此 ， 用 户 要 习惯 性 地 在 
更 新 操作 时 指定 保留 旧版 本 。 
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图 5-10 ”Deployment 的 版 本 历史 记录 


注意 ”为 了 保存 版 本 升级 的 历史 ， 需 要 在 创建 Deployment 对 
象 时 于 命令 中 使 用 “--record” 选 项 。 


尽管 深 动 更 新 以 市 约 系 统 资源 著称 ， 但 它 也 存在 一 些 务 势 。 和 直接 改 
动 现 有 环境， 会 使 系统 引入 不 确定 性 风险 ， 而 且 升 级 过 程 出 现 问题 后 ， 
执行 回 深 操 作 也 会 较为 缓慢 。 有 和 鉴于 此 ， 金 丝 稚 部 获 可 能 是 较为 理想 的 
实现 方式 ， 当 然 ， 如 果 不 考虑 系统 资源 的 可 用 性 ， 那么 传统 的 蓝 绿 部 署 
也 是 不 错 的 选择 。 


5.3.3 ”升级 Deployment 


修改 Pod 模 板 相 关 的 配置 参数 便 能 完成 Deployment 控 制 器 资源 的 更 
新 。 由 于 是 声明 式 配置 ， 因 此 对 Deployment 控 制 器 资源 的 修改 尤其 适合 
使 用 apply 和 patch 命 令 来 进行 ， 当 然 ， 如 果 仪 是 修改 容器 镜像 ，“set 
image” 命 令 更 为 易 用 。 


接 下 来 通过 更 新 此 前 创建 的 Deployment 控 制 器 deploy-example 来 了 
解 更 新 操作 过 程 的 执行 细节 ， 为 了 使 得 升级 过 程 更 易于 观测 ， 这 里 先 使 
用 “kubectl patch”* 命 令 为 其 spec.minReadySeconds 字 有 段 定 义 一 个 等 待 时 
长 ， 例 如 5s: 





~]$ kubectl1 patch deployments myapp-deploy -p '{"spec": {"minReadySeconds": 5}}' 
deployment .extensions "myapp-deploy" patched 





patch 命 令 的 补丁 形式 为 JSON 格 式 ， 以 -p 选 项 指定 ， 上 面 命令 中 
的 '{"spec": {"minReadySeconds": 5}} 表 示 设 置 spec.minReadySeconds 属 
性 的 值 。 若 要 改变 myapp-deploy 中 myapp 容 器 的 镜像 ， 也 可 使 用 patch 命 
令 ， 如 '{"'spec": {"containers": 
["name": "myapp"，"image""ikubernetes/myapp: V2"}}， 不 过 ， 修 改 容 
器 镜像 有 更 为 简单 的 专用 命令 "set image”。 





© 注意 ”修改 Deployment 控 制 占 的 minReadySeconds、replicas 和 
strategy 等 字段 的 值 并 不 会 触发 Pod 资 源 的 更 新 操作 ， 因 为 它们 不 属于 模 
板 的 内 髓 字段 ， 对 现存 的 Pod 对 象 不 产生 任何 影响 。 


接着 ， 使 用 “ikubernetes/myapp: v2” 镜像 文件 修改 Pod 模 板 中 的 
myapp 容 器 ， 启 动 Deployment 控 制 器 的 深 动 更 新 过 程 : 








~]$ kubect1 set image deployments myapp-deploy myapp=ikubernetes/myapp:v2 
deployment.apps "myapp-deploy" image updated 





“kubectl rollout status” 命 令 可 用 于 打印 滚动 更 新 过 程 中 的 状态 信 
息 .: 





~]$ kubect1 rollout status deployments myapp-deploy 





另外 ， 还 可 以 使 用 “kubectl get deployments--watch” 命 令 监 控 其 更 新 
过 程 中 Pod 对 象 的 变动 过 程 : 








~]$ kubect1 get deployments myapp-deploy --watch 





滚动 更 新 时 ，myapp-deploy 控 制 器 会 创建 一 个 新 的 ReplicaSet 控 制 器 
对 和 象 来 管控 新 版 本 的 Pod 对 象 ， 升 级 完成 后 ， 旧 版 本 的 ReplicaSet 会 保留 
在 历史 记录 中 ， 但 其 此 前 的 管控 Pod 对 象 将 会 被 删除 。 








~]$ kubectl1 get replicasets -1 app=myapp 


NAME DESIRED CURRENT READY AGE 
myapp-deploy-79859f456c 3 3 3 1m 
myapp-deploy-86b4b8c75d 0 0 0 Znm 





myapp-deploy 控 制 占 管控 的 Pod 资 源 对 象 也 将 随 之 更 新 为 以 新 版 本 
ReplicaSet 名 称 “myapp-deploy-79859f456c” 为 前 级 的 Pod 副 本 ， 命 令 结果 
如 下 所 示 : 





~]$ kubectl get pods -1 app=myapp 


NAME READY STATUS RESTARTS AGE 
myapp-deploy-79859f456c-29rqw 1/1 Running 0 16m 
myapp-deploy-79859f456c-fhhwf 1/1 Running 0 15m 
myapp-deploy-79859f456c-h4n9d 1/1 Running 0 15m 





由 于 已 经 处 于 READY 状 态 ， 因 此 上 面 命令 列 出 的 任 一 Pod 资 源 均 可 
正常 回 用 户 提 供 相关 服务 ， 例 如 ， 在 集群 内 任 一 能 使 用 kubectl 的 节点 访 
问 myapp-deploy-79859f456c-29rqw 中 的 Web 服 务 ， 命 令 如 下 : 





~]$ curl $(kubectl1 get pods myapp-deploy-79859f456c-29rqw -0 go-template={{. 
status.podIp}}) 
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a> 





5.3.4 金 丝 和 省 发 布 


Deployment 控 制 器 还 支持 自 定 义 控 制 更 新 过 程 中 的 深 动 节奏 ， 

如 “暂停 ”(pause) 或 “继续 ”(resume) 更 新 操作 ， 尤 其 是 借助 于 前 文 讲 
到 的 maxSurge 和 maxUnavailable 属 性 还 能 实现 更 为 精巧 的 过 程控 制 。 比 
如 ， 竺 第 一 批 新 的 Pod 资 源 创建 完成 后 立即 暂停 更 新 过 程 ， 此 时 ， 仅 存 
在 一 小 部 分 新 版 本 的 应 用 ， 主 体 部 分 还 是 旧 的 厂 本 。 然 后 ， 再 根据 用 户 
特征 精心 租 选 出 小 部 分 用 户 的 请 求 路 由 至 新 版 本 的 Pod 应 用 ， 并 持续 观 
察 其 是 否 能 稳定 地 按期 望 的 方式 运行 。 确 定 没有 问题 后 再 继续 完成 余下 
Pod 资 源 的 深 动 更 新 ， 人 否则 立即 回 湾 更 新 操作 。 这 便 是 所 谓 的 金 丝 人 逢 发 
布 (Canary Release) ， 如 图 5-11 所 示 。 


Loadbalancer 
(% ) 


图 5-11 人 金 丝 从 发 布 〈 图 片 来 源 : http://blog.christianposta.com ) 
拓展 知识 : 矿井 中 的 金 丝 稚 


17 世 纪 ， 英 国 矿井 工人 发 现 ， 金 丝 省 对 瓦斯 这 种 气体 十 分 敏感 。 空 
气 中 哪怕 有 极其 微量 的 瓦斯 气体 ， 金 丝 稚 也 会 停止 歌唱 ， 当 瓦斯 舍 量 超 
过 一 定 限 度 时 ， 人 类 依旧 坚 无 察觉 ， 而 金 丝 稚 却 早已 毒 发 身亡 。 当 时 在 
采矿 设备 相对 简陋 的 条 件 下 ， 工 人 们 每 次 下 井 都 会 珊 上 一 只 金 丝 省 作为 
瓦斯 检测 工具 ， 以 便 在 危险 状况 下 紧急 撤离 。 


直接 发 布 新 应 用 上 厂 本 的 在 线 发 布 形 式 中 ， 金 丝 省 发布 是 一 种 较为 习 
当 的 方式 。 不 过 ， 这 里 只 涉及 其 部 署 操 作 的 相关 步骤 ， 发 布 方式 则 通 第 
依赖 于 有 具体 的 环境 设置 。 接 下 来 说 明 如 何在 Kubernetes 上 使 用 
Deployment 控 制 右 实现 金 丝 省 部 团 。 

















为 了 尽 可 能 地 降低 对 现 有 系统 及 其 容量 的 影响 ， 金 丝 稚 发布 过 程 通 
党 建议 采用 “ 先 添加 、 再 删除 ， 且 可 用 Pod 资 源 对 象 总 数 不 低 于 期 望 
值 ” 的 方式 进行 。 首 次 添加 的 Pod 对 象 数量 取决 于 其 接 入 的 第 一 批 请 求 的 
规则 及 单个 Pod 的 承载 能 力 ， 视 具体 需求 而 定 ， 为 了 能 够 更 简单 地 说 明 
问题 ， 接 下 来 采用 首 批 添加 1 个 Pod 资 源 的 方式 。 将 Deployment 控 制 器 的 
maxSurge 属 性 的 值 设 置 为 1， 并 将 maxUnavailable 属 性 的 值 设 置 为 0: 








~]$ kubectl1 patch deployments myapp-deploy \ 

-p '{"spec": {"strategy":{"rollingUpdate": {"maxSurge": 1, "maxUnavailable": 
0}}}}" 

deployment .extensions "myapp-deploy" patched 











接 下 来 ， 局 动 myapp-deploy 控 制 器 的 更 新 过 程 ， 在 修改 相应 容器 的 
镜像 版 本 后 立即 暂停 更 新 进度 ， 它 会 在 启动 第 一 批 新 版 本 Pod 对 象 的 创 
建 操作 之 后 转 为 暂停 状态 。 需 要 注意 的 是 ， 这 里 之 所 以 能 够 在 第 一 批 更 
新 启动 后 就 暂停 ， 有 赖 于 此 前 为 maxReadySeconds 属 性 设置 的 时 长 ， 
此 用 户 要 在 更 新 命令 启动 后 的 此 时 长 指定 的 时 间 范 围 内 启动 暂停 操作 ， 
其 执行 过 程 如 图 5-12 所 示 。 当 然 ， 对 kubectl 命 令 来 说 ， 也 可 以 直接 
以 “&&e" 符 号 在 Shell 中 连接 两 个 命令 : 








~]$ kubect1 set image deployments myapp-deploy myapp=ikubernetes/myapp:v3 \ 
&& kubectl1l rollout pause deployments myapp-deploy 

deployment.apps "myapp-deploy" image updated 

deployment.apps "myapp-deploy" paused 
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图 5-12 ”暂停 Deployment 深 动 更 新 
通过 其 状态 查看 命令 可 以 看 到 ， 在 创建 完 一 个 新 版 本 的 Pod 资 源 后 








深 动 更 新 操作 “暂停 ”: 





~]$ kubectl1 rollout status deployments myapp-deploy 
Waiting for rollout to finish: 1 out of 3 new replicas have been updated... 








相关 的 Pod 列 表 也 可 能 显示 旧版 本 的 ReplicaSet 的 所 有 Pod 副 本 仍 在 
正常 运行 ， 新 版 本 的 ReplicaSet 也 包含 一 个 Pod 副 本 ， 但 最 多 不 超过 期 望 
值 1 个 ，myapp-deploy 原 有 的 期 望 值 为 ?9， 因 此 总 数 不 超 过 4 个 。 此 时 ， 
通过 Service 或 mgress 资 源 及 相关 路 由 策略 等 设 定 ， 即 可 将 一 部 分 用 户 的 
流量 引入 到 这 些 Pod 之 上 进行 发 布 验证 。 运 行 一 段 时 间 后 ， 如 果 确 认 没 
有 问题 ， 即 可 使 用 “kubectl rollout resume” 命 令 继续 此 前 的 滚动 更 新 过 
程 : 





~]$ kubectl1 rollout resume deployments myapp-deploy 
deployment.apps "myapp-deploy" resumed 








“kubectl rollout status” 命 令 监 控 到 滚动 更 新 过 程 完成 后 ， 即 可 通过 
myapp-deploy 控 制 器 及 其 ReplicaSet 和 Pod 对 象 的 相关 信息 来 了 解 其 结 
Na 太 
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然而 ， 如 果 “ 金 丝 稚 ?遇险 甚至 遭遇 不 地， 那么 回 滚 操 作 便 成 了 接 下 
来 的 当 紧 任务 。 


5.3.5” 回 滚 Deployment 控 制 器 下 的 应 用 发 布 


若 因 各 种 原因 导致 深 动 更 新 无 法 正常 进行 ， 如 镜像 文件 获取 失 
败 、“ 金 丝 逢 ?遇险 等 ， 则 应 该 将 应 用 回 滚 到 之 前 的 版 本 ， 或 者 回 滚 到 由 
用 户 指 定 的 历史 记录 中 的 版 本 。Deployment 控 制 器 的 回 滚 操作 可 使 
用 “kubectl rollout undo” 命 令 完 成 ， 例 如 ， 下 面 的 命令 可 将 myapp-deploy 
回 深 至 此 前 的 版 本 : 





~]$ kubectl1 rollout undo deployments myapp-deploy 
deployment.apps "myapp-deploy" 





等 回 深 完 成 后 ， 验 证 myapp-deploy 的 ReplicaSet 控 制 器 对 象 是 否 已 恢 
复 到 指定 的 历史 版 本 以 确保 其 回 深 正 常 完成 。 在 “kubectl rollout undo” 命 
令 上 使 用 “--to-revision” 选 项 指定 revision 号 人 码 即 可 回 深 到 历史 特定 版 本 ， 
例如 ， 假 设 myapp-deploy 包 含 如 下 的 revision 历 史记 录 : 








~]$ kubect1 rollout history deployments myapp-deploy 
deployments "myapp-deploy" 
REVISION CHANGE-CAUSE 


1 kubectl]1 patch deployments myapp-deploy --patch={"spec": {"minReady- 
Seconds": 5}} 

2 kubectl] patch deployments myapp-deploy --patch={"spec": {"strategy": 
{"rollingUpdate": {"maxSurge": 1, "maxUnavailable": 0}}}} 

3 kubect] set image deployments myapp-deploy myapp=ikubernetes/myapp:v3 

4 kubect] set image deployments myapp-deploy myapp=ikubernetes/myapp:v4 





奋 要 回 滚 到 号 码 为 2 的 revision 记 录 ， 则 使 用 如 下 命令 即 可 完成 : 





~]$ kubect1 rollout undo deployments myapp-deploy --to-revision=2 
deployment .apps "myapp-deploy" 





回 深 操作 中 ， 其 revision 记 录 中 的 信息 会 太 生 变动 ， 回 深 操 作 会 被 
当 作 一 次 滚动 更 新 退 加 进 历 史记 录 中 ， 而 被 回访 的 条 目 则 会 被 删除 。 需 
要 注意 的 是 ， 如 果 此 前 的 滚动 更 新 过 程 处 于 “和 暂停? 状态， 那么 回 深 操 作 
就 需要 先 将 Pod 模 板 的 版 本 改 回 到 之 前 的 版 本 ， 然 后 “继续 更新， 个 
则 ， 其 将 一 直 处 于 暂停 状态 而 无 法 回 滚 。 











5.3.6 ”扩容 和 缩 容 


通过 修改 .spec.replicas 即 可 修改 Deployment 控 制 器 中 Pod 资 源 的 副本 
数量 ， 它 将 实时 作用 于 控制 器 并 直接 生效 。Deployment 控 制 占 是 声明 式 
配置 ，replicas 属 性 的 值 可 直接 修改 资源 配置 文件 ， 然 后 使 用 “kubectl 
apply” 进 行 应 用 ， 也 可 以 使 用 "kubectl edit* 对 其 进行 实时 修改 。 而 前 一 
种 方式 能 够 将 修改 结果 了 予以 长 期 留存 。 


另外 , “kubectl scale” 是 专用 于 扩展 某 些 控制 器 类 型 的 应 用 规模 的 命 
令 ， 包 括 Deployment 和 Job 等 。 而 Deployment 通 过 ReplicaSet 控 制 其 Pod 资 
源 ， 因 此 扩 缩 容 的 方式 是 相同 的 ， 除 了 命令 直接 作用 的 资源 对 象 有 上 所 不 
同 之 外 ， 这 里 不 再 对 其 进行 展开 说 明 。 





5.4 DaemongsSet 控 制 器 


DaemonSet 是 Pod 控 制 器 的 又 一 种 实现 ， 用 于 在 集群 中 的 全 部 节点 
上 同时 运行 一 份 指定 的 Pod 资 源 副 本 ， 后 续 新 加 入 集群 的 工作 节点 也 会 
上 自动 创建 一 个 相关 的 Pod 对 象 ， 当 从 集群 移 除 节点 时 ， 此 类 Pod 对 象 也 将 
被 目 动 回收 而 无 顷 重建 。 管 理 员 也 可 以 使 用 节点 选择 器 及 节点 标签 指定 
仅 在 部 分 具有 特定 特征 的 节点 上 运行 指定 的 Pod 对 象 。 


DaemonSet 是 一 种 特殊 的 控制 器 ， 它 有 特定 的 应 用 场景 ， 通 各 运行 
那些 执行 系统 级 操作 任务 的 应 用 ， 其 应 用 场景 具体 如 下 。 


:运行 集群 存储 的 守护 进程 ， 如 在 各 个 节点 上 运行 glusterd 或 ceph。 
-在 各 个 节点 上 运行 日 志 收 集 守 护 进 程 ， 如 fluentd 和 logstash。 


-在 各 个 节点 上 运行 监控 系统 的 代理 守护 进程 ， 如 Prometheus Node 
Exporter、collectd、Datadog agent、New Relic agent 或 Ganglia gmond 
竺 


























当然 ， 既 然 是 需要 运行 于 集群 内 的 每 个 节点 或 部 分 节点 ， 于 是 很 多 
场景 中 也 可 以 把 应 用 直接 运行 为 工作 节点 上 的 系统 级 守护 进程 ， 不 过 ， 
这 样 一 来 就 失去 了 运用 Kubernetes 管 理 所 带 来 的 便捷 性 。 另 外 ， 也 只 有 
必须 将 Pod 对 象 运行 于 固定 的 几 个 节点 并 且 需 要 先 于 其 他 Pod 启 动 时 ， 才 
有 必要 使 用 DaemonSet 控 制 嚣 ， 否 则 束 应 该 使 用 Deployment 控 制 器 。 








5.4.1 创建 DaemonSet 资 源 对 象 





DaemonsSet 控 制 句 的 spec 字 段 中 般 套 使 用 的 字段 同样 主要 包 了 前 面 
讲 到 的 Pod 控 制 器 资源 支持 的 selector、template 和 minReadySeconds， 并 
且 功 能 和 用 法 基本 相同 ， 但 它 不 文 持 使 用 replicas， 毕 竟 DaemonSet 并 不 
是 基于 期 望 的 副本 数 来 控制 pod 资源 数量 ， 而 是 基于 市 点 数量 ， 但 
template 是 必 选 字段 。 


下 面 的 资源 清单 文件 〈filebeat-ds.yaml) 示例 中 定义 了 一 个 名 为 
filebeat-ds 的 DaemonSet 控 制 器 ， 它 将 在 每 个 节点 上 运行 一 个 flebeatj 进 程 
以 收集 容器 相关 的 日 志 数 据 : 














apiVersion: apps/vi1 
kind: DaemonSet 
metadata: 
name: filebeat-ds 
labels: 
app: filebeat 
spec: 
selector: 
matchLabels: 
app: filebeat 
template: 
metadata: 

lJabels: 
app: filebeat 

name: filebeat 

spec: 

containers: 

- name: filebeat 
image: ikubernetes/filebeat:5.6.5-alpine 
env: 

- Name: REDIS HOST 

value: db.ilinux.i0o:6379 
- Name: LOG_ LEVEL 

value: info 





通过 清单 文件 创建 DaemonSet 资 源 的 命令 与 其 他 资源 的 创建 并 无 二 
到 





~]$ kubect1l apply -f filebeat-ds.yaml 
daemonset ,apps "filebeat-ds" created 





OO 注意 ” 自 Kubermnetes 1.8 版 本 起 ，DaemonSet 也 必须 使 用 
selector 来 匹配 Pod 横 板 中 指定 的 标签 ， 而 且 它 也 文 持 matchLabels 和 
matchExpressions 两 种 标签 选择 器 。 


与 其 他 资源 对 象 相 同 ， 用 户 也 可 以 使 用 “kubectl describe” 命 令 查 看 
DaemonSet 对 象 的 详细 信息 。 下 面 命令 的 结果 信息 中 ，Node-Selector 字 
段 的 值 为 室 ， 表 示 它 需要 运行 于 集群 中 的 每 个 节点 之 上 。 而 当前 集群 的 
节点 数量 为 3， 因 此 ， 其 期 望 的 Pod 副 本 数 (Desired Number of Nodes 
Scheduled) 为 3， 而 当前 也 已 经 成 功 创建 了 3 个 相关 的 Pod 对 象 : 














~]$ kubectl1 describe daemonsets filebeat-ds 

Name: filebeat-ds 

Selector: app=filebeat 

Node-Selector: <none> 

Desired Number of Nodes Scheduled: 3 

Current Number of Nodes Scheduled: 3 

Number of Nodes Scheduled with Up-to-date Pods: 3 

Number of Nodes Scheduled with Available Pods: 3 

Number of Nodes Misscheduled: 0 

Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed 





根据 DaemonSet 资 源 本 身 的 意义 ，filebeat-ds 控 制 器 成 功 创建 的 3 个 
Pod 对 象 应 该 分 别 运行 于 集群 中 的 每 个 节点 之 上 ， 这 一 点 可 以 通过 如 下 
命令 进行 验证 : 





~]$ kubectl get pods -1 app=filebeat \ 

-0 CusStom-columns=NAME :metadata.name, NODE: spec.nodeName 
NAME NODE 

filebeat-ds-sjrvb node01.ilinux.io 

filebeat-ds-swd47 node03.ilinux.io 

filebeat-ds-z7r97 node02.ilinux.io 








集群 中 的 部 分 工作 节点 偶尔 也 存在 需要 将 Pod 对 象 以 单一 实例 形式 
运行 的 情况 ， 例 如 对 于 拥有 特殊 硬件 的 节点 来 说 ， 可 能 会 需要 为 其 运行 
特定 的 监控 代理 (agent) 程序 ， 等 等 。 其 实现 方式 与 前 面 讲 到 的 Pod 资 
源 的 节点 绑 定 机 制 关 似 ， 只 需要 在 Pod 模 板 的 Spec 字 段 中 藤 套 使 用 
nodeSelector 字 上段， 并 确保 其 值 定义 的 标签 选择 器 与 部 分 特定 工作 节点 
的 标签 匹配 即 可 。 





5.4.2 ”更 新 DaemonSet 对 象 


DaemonSet 自 Kubernetes 1.6 版 本 起 也 开始 支持 更 新 机 制 ， 相 关 配 置 
定义 在 spec.update-Strategy 舱 套 字 段 中 。 目 前 ， 它 支持 
RollingUpdate〈 滚 动 更 新 )》 和 OnDelete〈 删 除 时 更 新 ) 两 种 更 新 策略 ， 
深 动 更 新 为 默认 的 更 新 策略 ， 工 作风 辑 类 似 于 Deployment 控 制 ， 不 过 仪 
文 持 使 用 maxUnavailabe 属 性 定义 最 大 不 可 用 Pod 资 源 副 本 数 默 认 值 为 
ee 除 时 更 新 的 方式 则 是 在 删除 相应 节点 的 Pod 资 源 后 重建 并 更 新 


例如 ， 将 此 前 创建 的 flebeat-ds 中 Pod 模 板 中 的 容 吉 镜像 升级 
为 “ikubernetes/filebeat: 5.6.6-alpine”， 使 用 “kubectl set image” 命 令 即 可 
实现 : 














~]$ kubect1 set image daemonsets filebeat-ds filebeat=ikubernetes/filebeat:5.6.6- 
alpine 
daemonset .apps "filebeat-ds" image updated 





由 下 面 命令 的 返回 结果 可 以 看 出 ， 亿 ebeat-ds 控 制 嚣 Pod 模板 中 的 容 
器 镜像 文件 已 经 完成 更 新 ， 对 深 动 更 新 策略 来 说 ， 它 会 目 动 触发 更 新 操 
作 。 用 户 也 可 以 通过 filebeat-ds 控 制 占 的 详细 信息 中 的 Events 字 上 段 等 来 了 
解 深 动 更 新 的 操作 过 程 。 由 下 面 的 命令 结果 可 以 看 出 ， 默 认 的 深 动 更 新 
策略 是 一 次 删除 一 个 工作 节点 上 的 Pod 资 源 ， 待 其 新 版 本 Pod 资 源 重建 完 
成 后 再 开始 操作 男 一 个 工作 节点 上 的 Pod 资 源 : 





~]$ kubectl describe daemonsets filebeat-ds 


Events 

Type Reason Age From Message 

Normal SuccessfulDelete 3m daemonset-controller Deleted pod: filebeat- 
ds-swd47 

Normal SuccessfulCreate 3m daemonset-controller Created pod: filebeat- 
ds-pnhvil 

Normal SuccessfulDelete 3m daemonset-controller Deleted pod: filebeat- 
ds-z7r97 

Normal SuccessfulCreate 2m daemonset-controller Created pod: filebeat- 
ds-z2wdv 

Normal SuccessfulDelete 2m daemonset-controller Deleted pod: filebeat- 
ds-sjrvb 


Normal SuccessfulCreate 2m daemonset-controller Created pod: filebeat- 


ds-6pvdb 





DaemonSet 控 制 器 的 滚动 更 新 机 制 也 可 以 借助 于 minReadySeconds 字 
段 控制 滚动 节奏 ， 必 要 时 可 以 执行 芹 停 和 继续 操作 ， 因 此 它 也 能 够 设计 
为 金 丝 汰 发 布 机 制 。 另 外 ， 故 障 的 更 新 操作 也 可 以 进行 回 滚 ， 包 括 回 滚 
至 revision 历 史记 录 中 的 任何 一 个 指定 的 版 本 。 鉴 于 篇 幅 ， 这 里 不 再 给 
中 六 感 兴趣 的 读者 可 参考 Deployment 控 制 器 的 步 又 测试 其 实 
现 。 





5.5 ” Job 控制 器 


与 Deployment 及 DaemonSet 控 制 器 管理 的 守护 进程 类 的 服务 应 用 不 
同 的 是 ，Job 控 制 器 用 于 调配 Pod 对 象 运 行 一 次 性 任务 ， 容 器 中 的 进程 在 
正常 运行 结束 后 不 会 对 其 进行 重启 ， 而 是 将 Pod 对 象 置 
于 “Completed”( 完 成 ) 状态 。 知 容器 中 的 进程 因 错 误 而 终止 ， 则 需要 
依 配 置 确定 重启 与 否 ， 未 运行 完成 的 Pod 对 象 因 其 所 在 的 节点 故障 而 意 
外 终止 后 会 被 重新 调度 。Job 控 制 器 的 Pod 对 象 的 状态 转换 如 图 5-13 所 


人 外 O 
| Pod(exit 0) Completed 


Pod(exit !0) 
| restartPolicy:Never 


it ! 
Eder 10) . Pod(exit 0) Completed 
restartPolicy:OnFailure 


Failure.Restart 








Failure 











图 5-13 Job 管理 下 Pod 资 源 的 运行 方式 


实践 中 ， 有 的 作业 任务 可 能 需要 运行 不 止 一 次 ， 用 户 可 以 配置 它们 
ee 总 结 起 来 ， 这 种 类 型 的 Job 控 制 器 对 象 有 两 
和 种， 具体 如 下 。 


单 工作 队列 (work queue) 的 串 行 式 Job: 即 以 多 个 一 次 性 的 作业 
方式 串 行 执行 多 次 作业 ， 直 至 满足 期 望 的 次 数 ， 如 网 5-14 所 示 ; 这 次 
在 某 个 时 刻 仅 存在 一 个 
Pod 资 源 对 象 。 





' Job Controller ! 


\ 


图 5-14 串 行 式 多 任务 


:多 工作 队列 的 并 行 式 Job: 这 种 方式 可 以 设置 工作 队列 数 ， 即 作业 
数 ， 每 个 队列 仅 负 责 运行 一 个 作业 ， 如 图 5-15a 所 示 ; 也 可 以 用 有 限 的 
工作 队列 运行 较 多 的 作业 ， 即 工作 队列 数 少 于 总 作业 数 ， 相 当 于 运行 多 
0 
源 数 。 
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a) b) 
图 5-15 ”多 队列 并 行 式 多 任务 


Job 控 制 者 常用 于 管理 那些 运行 一 段 时 间 便 可 “完成 ”的 任务 ， 例 如 
计算 或 备份 操作 。 


5.5.1 创建 Job 对 象 


Job 控 制 嚣 的 spec 字 段 内 髓 的 必要 字段 仅 为 template， 它 的 使 用 方式 
与 Deployment 等 控制 器 并 无 不 同 。Job 会 为 其 Pod 对 象 自 动 添加 “job- 
name=JOB_NAME” 和 “controller-uid=UID” 标 签 ， 并 使 用 标签 选择 器 完成 
对 controller-uid 标 签 的 关联 。 需 要 注意 的 是 ，Job 位 于 API 群 
组 "batch/y 之 内 。 下 面 的 资源 清单 文件 〈job-example.yaml) 中 定义 了 
一 个 Job 控 制 器 








apiVersion: batch/vi 
kind: Job 
metadata: 
name: job-example 
spec: 
template: 
spec: 
containers: 
- name: myjob 
image: alpine 
command: ["/bin/sh", "-c", "sleep 120"] 
restartPolicy: Never 





© 注意 ”Pod 模板 中 的 spec.restartPolicy 默 认为 “Always”"， 这 对 
Job 控 制 器 来 说 并 不 适用 ， 因 此 必须 在 Pod 模 板 中 显 式 设 定 restartPolicy 属 
性 的 值 为 “Never” 或 “OnFailure”。 


使 用 “kubectl create” 或 “kubectl apply”* 命 令 完成 创建 后 即 可 查 0 大 
的 任务 状态 ，DESIRED 字 段 表 示 期 望 并 行 运 行 的 Pod 资 源 数量 ， 而 
SUCCESSFUL 则 表示 成 功 完 成 的 Job 数 : 








~]$ kubectl1 get jobs job-example 
NAME DESIRED SUCCESSFUL AGE 
job-example 1 0 7S 





相关 的 Pod 资 源 能 够 以 Job 控 制 器 名 称 为 标签 进行 匹配 : 





~]$ kubectl get pods -1 job-name=job-example 
NAME READY STATUS RESTARTS AGE 
job-example-6c5g8 1/1 Running 0 20s 





其 详细 信息 中 可 显示 所 使 用 的 标签 选择 器 及 匹配 的 Pod 资 源 的 标 
签 ， 具 体 如 下 : 





~]$ kubectl1 describe jobs job-example 


Name : job-example 

Namespace: default 

Selector: controller-uid=48ae496f-1e81-11e8-9267-000c29abof5b 

Labels: controller-uid=48ae496f-1e81-11e8-9267-000c29abof5b 
job-name=job-example 

Annotations: <none> 

Parallelism: 1 

Completions: 1 








两 分 钟 后 ， 竺 sleep 命令 执行 完成 并 成 功 退 出 后 ，Pod 资 源 即 转 换 为 
Completed 状 态 ， 并 且 不 会 再 于 “kubectl get pods” 命 令 中 出 现 ， 除 非 为 其 
使 用 选项 “--show-all” 或 简单 格式 的 “-a”: 





~]$ kubectl1 get pods -1 job-name=job-example -a 
NAME READY STATUS RESTARTS AGE 
job-example-6c5g8 0/1 Completed 0 3m 





此 时 ， 如 果 使 用 “kubectl get jobs” 显 示 job-example 的 相关 信息 ， 那 
其 SUCCESSFUL 字 段 的 数字 就 不 再 为 "0”。 


5.5.2 ”并 行 式 Job 


将 并 行 度 属性 .spec.parallelism 的 值 设置 为 1， 并 设置 总 任务 
数 . spec.completion 属 性 便 能 够 让 Job 控 制 器 以 串 行 方式 运行 多 任务 。 下 面 
是 一 个 串 行 运行 5 次 任务 的 Job 控 制 器 示例 : 





apiVersion: batch/vi 
kind: Job 
metadata: 
name: job-multi 
spec: 
completions: 5 
template: 
spec: 
containers: 
- name: myjob 
image: alpine 
command: ["/bin/sh", "-c", "sleep 20"] 
restartPolicy: OnFailure 





在 创建 之 后 或 者 创建 之 前 ， 可 以 于 另 一 终端 启动 Pod 资 源 的 列 出 命 
令 “kubect] get pods-] job-name=job-multi--watch” 来 监控 其 变动 ， 以 了 解 
其 执行 过 程 。 


.Spec.parallelism 能 够 定义 作业 执行 的 并 行 度 ， 将 其 设置 为 2 或 者 以 
上 的 值 即 可 实现 并 行 多 队列 作业 运行 。 同 时 ， 如 果 .spec.completions 使 用 
的 是 默认 值 1， 则 表示 并 行 度 即 作业 总 数 ， 如 网 5-15a 所 示 ;， 而 如 果 
将 .spec.completions 属 性 值 设置 为 大 于 .spec.parallelism 的 属性 值 ， 则 表示 
使 用 多 队列 串 行 任务 作业 模式 ， 如 图 5-15b 所 示 。 例 如 ， 
置 中 的 spec 字 段 鞭 套 了 如 下 属性 ， 表 示 以 2 个 队列 并 行 的 方式 ， 总 共 运 
行 5 次 的 作业 : 














spec: 
completions: 5 
parallelism: 2 





5.5.3 ”Job 扩容 





Job 控 制 器 的 .spec.parallelism 定 义 的 并 行 度 表示 同时 运行 的 Pod 对 象 
数 ， 此 属 性 值 文 持 运 行 时 凋 竖 从 而 改变 其 队列 总 数 ， 实现 扩容 和 纵容。 
使 用 的 命令 与 此 前 的 Deployment 对 象 相同 ， 即 “kubectl scale--replicas” 命 
例如 在 其 运行 过 程 中 (未 完成 之 前 〉 将 job-multi 的 并 行 度 扩展 为 两 
路 : 











~]$ kubectl1 scale jobs job-multi --replicas=2 
job.apps "job-multi" scaled 








估 行 合 令 后 可 以 看 到 ， 其 同时 运行 的 Pod 对 象 副本 数量 立即 扩展 到 
于 两 个 : 





~]$ kubectl get pods -1 job-name=job-multi 


NAME READY STATUS RESTARTS AGE 
job-multi-c26rh 0/1 ContainerCreating 0 2S 
job-multi-tfj9k 1/1 Running 0 26S 





根据 工作 节点 及 其 :资源 可 用 量 ， 适度 提高 Job 的 并 行 度 ， 能 够 大 大 
提升 其 完成 效率 ， 缩 短 运 行 时 间 。 


5.5.4 删除 Job 


Job 控 制 句 符 其 Pod 资 源 运行 完成 后 ， 将 不 再 占用 系统 资源 。 用 户 可 
按 需 保留 或 使 用 资源 删除 命令 将 其 删除 。 不 过 ， 如 果 某 Job 控 制 器 的 容 
器 应 用 总 是 无 法 正常 结束 运行 ， 而 其 restartPolicy 又 定 为 了 重启 ， 则 它 可 
能 会 一 直 处 于 不 停 地 重启 和 错误 的 循环 当中 。 所 邓 的 是 ，Job 控 制 器 提 
供 了 两 个 属性 用 于 抑制 这 种 情况 的 发 生 ， 有 具体 如 下 。 


.spec.activeDeadlineSeconds<integer> : Job 的 deadline， 用 于 为 其 指 
定 最 大 活动 时 间 长 度 ， 超 出 此 时 长 的 作业 将 被 终止 。 

.spec.backoffLimit<integer> : 将 作业 标记 为 失败 状态 之 前 的 重 试 次 
数 ， 默 认 值 为 6。 


例如 ， 下 面 的 配置 片断 表示 其 失败 重 试 的 次 数 为 5， 并 且 如 果 超 出 
100 秒 的 时 间 仍 未 运行 完成 ， 那 么 其 将 被 终止 : 








spec: 
backoffLimit: 5 
activeDeadlineSeconds: 100 





5.6 ”CronJob 控 制 器 


CronJob 控 制 器 用 于 管理 Job 控 制 器 资源 的 运行 时 间 。Job 控 制 右 定义 
的 作业 任务 在 其 控制 器 资源 创建 之 后 便 会 立即 执 行 ， 但 CronJob 可 以 以 
类 似 于 Linux 操 作 系 统 的 周期 性 任务 作业 计划 (crontab〉 的 方式 控制 其 
运行 的 时 间 点 及 重复 运行 的 方式 ， 具 体 如 下 。 


:在 未 来 某 时 间 点 运行 作业 一 次 。 
.在 指定 的 时 间 点 重复 运行 作业 。 
CronJob 对 象 支 持 使 用 的 时 间 格 式 类 似 于 Crontab， 略 有 不 同 的 是 ， 


CronJob 控 制 占 在 指定 的 时 间 扣 时，“* 和 “*” 的 意义 相同 ， 痢 表示 任何 可 
用 的 有 效 值 。 








5.6.1 创建 CronJob 对 象 


CronJob 探 制 占 的 spec 字 上 段 可 多 套 使 用 以 下 字段 。 


jobTemplate<Object>: Job 控 制 器 模板 ， 用 于 为 CronJob 控 制 器 生成 
Job 对 象 ， 必 选 字段 。 


schedule<string>: Cron 格 式 的 作业 调度 运行 时 间 点 ; 必 选 字段 。 





concurrencyPolicy<string>: 并 发 执行 策略 ， 可 用 值 有 “Allow”( 人 允 
许 ) 、“Forbid”(〈 禁 止 ) 和 “Replace”( 蔡 换 ) ， 用 于 定义 前 一 次 作业 运 
行 尚 未 完成 时 是 否 以 及 如 何 运行 后 一 次 的 作业 。 


failedJobHistoryLimit<integer>: 为 失败 的 任务 执行 保留 的 历史 记录 
数 ， 默 认为 1。 


“successfulJobsHistoryLimit<integer>: 为 成 功 的 任务 执行 保留 的 历 
史记 录 数 ， 默 认为 3。 


startingDeadlineSeconds<integer>: 因 各 种 原因 缺乏 执行 作业 的 时 间 
点 所 导致 的 启动 作业 错误 的 超时 时 长 ， 会 被 记 入 错误 历史 记录 。 


suspend<boolean>: 是 耕 挂 起 后 续 的 任务 执行 ， 默 认为 false， 对 运 
行 中 的 作业 不 会 产生 影响 。 


下 面 是 一 个 定义 在 资源 清单 文件 (cronjob-example.yaml)〉 中 的 
CronJob 资 源 对 象 示例 ， 它 每 隔 2 分 钟 运行 一 次 由 jobTemplate 定 义 的 简单 
任务 : 








apiVersion: batch/v1betal 
kind: CronJob 
metadata: 
name: cronjob-example 
labels: 
app: mycronjob 
spec: 
schedule: ™*/2 * * * *" 
jobTemplate: 
metadata: 
labels: 


app: mycronjob-jobs 
spec: 
parallelism: 2 
template: 
spec: 

containers: 

- name: myjob 
image: alpine 
command: 

- /bin/sh 
-C 


- date; echo Hello from the Kubernetes cluster; sleep 10 
restartPolicy: OnFailure 





运行 资源 创建 命令 创建 上 述 CronJob 资 源 对 象 ， 而 后 再 通过 资源 对 
象 的 相关 信息 了 解 运行 状态 。 下 面 命令 结果 中 的 SCHEDULE 是 指 其 调 
度 时 间 点 ，SUSPEND 表 示 后 续 任 务 是 否 处 于 挂 起 状态 ， 即 暂停 任务 的 
调度 和 运行 ，ACTIVE 表 示 活 动 状态 的 Job 对 象 的 数量 ， 而 LAST 
SCHEDULE 则 表示 上 次 调度 运行 至 此 刻 的 时 长 : 











~]$ kubectl1 get cronjobs cronjob-example 
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE 
cronjob-example /2 False 1 37S 1m 





名 提示 “ 自 Kubernetes 1.8 起 ，CronJob 资 源 所 在 的 API 资 源 组 从 
batch/v2alphal 移 至 batch/vlbetal 中 ， 并 且 碍 看 其 资源 格式 时 也 要 使 用 -- 
api-version 选 项 指定 其 所 在 的 资源 组 ， 即 “kubectl explain cronjob--api- 
version='batch/vlbetal"”™。 





5.6.2 ”CronJob 的 控制 机 制 


CronJob 探 制 占 是 一 个 更 高 级 别 的 资源 ， 它 以 Job 控 制 器 资源 为 其 管 
控 对 象 ， 并 借助 它 管理 Pod 资 源 对 象 。 因 此 ， 要 使 用 类 似 如 下 命 命 令 来 查 
看 某 CronJob 控 制 器 创建 的 Job 资 源 对 象 ， 其 中 的 标签 "mycronjob-jobs" 是 是 
在 创建 cronjob-example 时 为 其 指定 。 不 过 ， 只 有 相关 的 Job 对 象 被 调度 执 
行 时 ， 此 命令 才能 将 其 正常 列 出 。 可 列 出 的 Job 对 象 的 数量 取决 于 
CronJob 资 源 的 .spec.successfulJobsHistoryLimit 的 属性 值 ， 默 认为 3。 





ee kubectl1 get jobs -1 app=mycronjob-jobs 


NAM DESIRED SUCCESSFUL AGE 
Be example-1520057880 <none> 2 5m 
cronjob-example-1520058000 <none> 2 3m 
cronjob-example-1520058120 <none> 2 1m 





如 果 作 业 重 复 执 行 时 指定 的 时 间 点 较 近 ， 而 作业 执行 时 长 (普遍 或 
偶尔 ) 路 过 了 其 两 次 执行 的 时 间 长 度 ， 则 会 出 现 两 个 Job 对 象 同时 存在 
的 情形 。 有 些 Job 对 象 可 能 会 存在 无 法 或 不 能 同时 运行 的 情况 ， 这 个 时 
候 就 要 通过 .spec.concurrencyPolicy 属 性 控制 作业 并 存 的 机 制 ， 其 默认 值 
为 “Allow”， 即 允许 前 后 Job， 甚 至 属于 同一 个 CronJob 的 更 多 Job 同 时 运 
J。 其 他 两 个 可 用 值 中 ，“Forbid” 用 于 禁止 前 后 两 个 Job 同 时 运行 ， 如 果 
前 一 个 尚未 结束 ， 后 一 个 则 不 予 启 动 〈 跳 过 ) ，“Replace”" 用 于 让 后 一 个 
Job 取 代 前 一 个 ， 即 终止 前 一 个 并 启动 后 一 个 。 





5.7 ReplicationController 


ReplicationController 〈 简 称 rc 或 RC) 是 Kubernetes 较 早 实现 的 Pod 控 
制 器 ， 用 于 确保 Pod 资 源 的 不 间断 运行 。 不 过 ，Kubernetes 后 来 设计 了 
ReplicaSet 及 其 更 高 一 级 的 控制 器 Deployment 来 取 ReplicationController， 
并 表示 在 后 来 的 版 本 中 可 能 会 上 废弃 RC。 因 此 ， 这 里 不 再 对 
ReplicationController 做 过 多 的 介绍 。 事 实 上 ， 它 的 使 用 方式 与 ReplicaSet 
人 同 rol 到 时 ， 绝 大 多 数 操作 都 可 以 迁移 使 用 ， 感 兴趣 的 读者 可 以 

行 测 试 。 





5.8 Pod 中 断 预算 


尽管 Deployment 或 ReplicaSet 一 类 的 控制 器 能 够 确保 相应 Pod 对 象 的 
副本 数量 不 断 通 近期 望 的 数量 ， 但 它 却 无 法 保证 在 某 一 时 刻 一 定 会 存在 
指定 数量 或 比例 的 Pod 对 象 ， 然 而 这 种 需求 在 某 些 强调 服务 可 用 性 的 场 
景 中 却 是 必 备 的 。 于 是 ，Kubernetes 自 1.4 厂 本 起 开始 引入 Pod 中 断 预 算 
(PodDisruptionBudget， 简 称 PDB ) 类 型 的 资源 ， 用 于 为 那些 自愿 的 
(Voluntary) 中 断 做 好 预算 方案 (Budget) ， 限 制 可 上 自愿 中 断 的 最 大 
Pod 副 本 数 或 确保 最 少 可 用 的 Pod 副 本 数 ， 以 确保 服务 的 高 可 用 性 。 


Pod 对 象 会 一 直 存 在 ， 除 非 有 意 将 其 销毁 ， 或 者 出 现 了 不 可 避免 的 
人 硬件 或 系统 软件 错误 。 非 上 自愿 中 断 是 指 那些 由 不 可 控 外 界 因 系 导 致 的 
Pod 中 断 退 出 操作 ， 例 如 ， 硬 件 或 系统 内 核 故 障 、 网 络 故障 以 及 节点 资 
源 不 足 导致 Pod 对 象 被 驱逐 等 ， 而 那些 由 用 户 特地 执行 的 管理 操作 导致 
的 Pod 中 断 则 称 为 "上 自愿 中 断 ”， 例 如 排 空 节 点 、 人 为 删除 Pod 对 象 、 由 
更 新 操作 触发 的 Pod 对 象 重建 等 。 部 署 在 Kubernetes 的 每 个 应 用 程序 都 可 
以 创建 一 个 对 应 的 PDB 对 象 以 限制 自愿 中 断 时 最 大 可 以 中 断 的 副本 数 或 
者 最 少 应 该 保持 可 用 的 副本 数 ， 从 而 保证 应 用 上 自身 的 高 可 用 性 。 


PDB 资 源 可 以 用 来 保护 由 控制 器 管理 的 应 用 ， 此 时 几乎 必然 意味 着 
PDB 使 用 等 同 于 相关 控制 器 对 象 的 标签 选择 器 以 精确 关联 至 目标 Pod 对 
象 ， 支 持 的 控制 器 类 型 包括 Deployment、ReplicaSet 和 StatefulSet 等 。 同 
由 以 用 来 保护 那些 纯粹 是 由 定制 的 标签 选择 器 自由 选择 

JPod 对 和 家。 


定义 PDB 资源 时 ， 其 spec 字 段 主要 仍 套 使 用 以 下 三 个 字段 。 


selector<Object>: 当前 PDB 对 象 使 用 的 标签 选择 器 ， 一 般 是 与 相关 
的 Pod 控 制 器 使 用 同一 个 选择 器 。 


minAvailable<string>: Pod 上 自愿 中 断 的 场景 中 ， 至 少 要 保证 可 用 的 
Pod 对 象 数 量 或 比例 ， 要 阻止 任何 Pod 对 象 发 生 上 自愿 中 断 ， 可 将 其 设置 为 
100%。 


-maxUnavailable<string>: Pod 自 愿 中 断 的 场景 中 ， 最 多 可 转换 为 不 
可 用 状态 的 Pod 对 象 数 量 或 比例 ，0 值 意味 着 不 允许 Pod 对 象 进行 自愿 中 





























断 ， 此 字段 与 ninAvailable 互 斥 。 


下 面 的 示例 定义 了 一 个 PDB 对 象 ， 它 对 5.3.1 节 中 由 Deployment 控 制 
器 myapp-deploy 创 建 的 Pod 对 象 设 置 了 Pod 中 断 预算 ， 要 求 其 最 少 可 用 的 
Pod 对 象 数 量 为 2 个 : 








apiVersion: policy/vibeta1 
kind: PodDisruptionBudget 
metadata: 

name: myapp-pdb 
spec: 

minAvailable: 2 

selector: 

matchLabels: 
app: myapp 





PDB 资 源 对 象 创建 完成 后 ， 在 它 的 简要 信息 输出 中 也 标明 了 最 少 可 
用 的 Pod 对 象 个 数 ， 以 及 允许 中 断 的 Pod 对 象 个 数 : 





~]$ kubectl1 get pdb 
NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE 
myapp-pdb 2 N/A 1 24S 





接 下 来 可 通过 命令 手动 删除 myapp-deploy 控 制 器 下 的 所 有 Pod 对 象 
模拟 目 愿 中 断 过 程 ， 并 监控 各 Pod 对 象 被 终止 的 过 程 来 验证 PDB 资源 对 
象 的 控制 功效 。 


5.9 本 章 小 结 


本 章 主 要 讲解 了 Kubernetes 的 Pod 控 制 器 ， 它 们 是 “工作 负载 ?类 资源 
的 核心 组 成 部 分 ， 是 基于 Kubernetes 运 行 应 用 的 最 重要 的 资源 类 型 之 
下 


工作 负载 类 型 的 控制 占 根 据 业 务 需 求 管控 Pod 资 源 的 生命 周期 。 


ReplicaSet 可 以 确保 守护 进程 型 的 Pod 资 源 始终 具有 精确 的 、 处 于 
运行 状态 的 副本 数量 ， 并 支持 Pod 规 模 的 伸缩 机 制 ， 它 是 新 一 代 的 
ReplicationController 控 制 器 ， 不 过 用 户 通常 不 应 该 直接 使 用 ReplicaSet， 
而 是 要 使 用 Deployment。 


.Deployment 是 建构 在 ReplicaSet 上 的 更 加 抽象 的 工作 负载 型 控制 
器 ， 文 持 多 种 更 新 策略 及 发 布 机 制 。 


:Job 控 制 嚣 能够 控制 相应 的 作业 任务 得 以 正常 完成 并 退出 ， 支 持 并 
行 式 多 任务 。 

:CronJob 控 制 器 用 于 控制 周期 性 作业 任务 ， 其 功能 类 似 于 Linux 操 作 
系统 上 的 Crontab。 


-PodDisruptionBudget 资 源 对 象 为 Kubernetes 系 统 上 的 容器 化 应 用 提 
供 了 高 可 用 能 力 。 
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运行 于 Pod 中 的 部 分 容器 化 应 用 是 同 客 户 病 提供 服务 的 守护 进程 ， 
例如 ，nginx、tomcat 和 etcd 等 ， 它 们 受 控 于 控制 器 资源 对 象 ， 存 在 生命 
周期 ， 在 自愿 或 非 自 愿 中 断后 只 能 被 重 构 的 新 Pod 对 象 所 取代 ， 属 于 非 
可 再 生 类 的 组 件 。 于 是 ， 在 动态 、 弹 性 的 管理 模型 下 ，Service 资 源 用 于 
为 此 类 Pod 对 象 提供 一 个 固定 、 统 一 的 访问 接口 及 负载 均衡 的 能 力 ， 并 
文 持 借助 于 新 一 代 DNS 系 统 的 服务 发 现 功能 ， 解 决 客户 端 发 现 并 访问 容 
器 化 应 用 的 难题 。 


然而 ，Service 及 Pod 对 象 的 卫 地 址 都 仅 在 Kubernetes 集 群 内 可 达 ， 它 
们 无 法 接 入 集群 外 部 的 访问 流量 。 解 决 此 类 问题 的 办 法 中 ， 除 了 在 单一 
节点 上 做 端口 暴露 (hostPort) 及 让 Pod 资 源 共享 使 用 工作 节点 的 网 络 名 
称 空间 (hostNetwork) 之 外 ， 更 推荐 用 户 使 用 的 是 NodePort 或 
LoadBalancer 类 型 的 Service 资 源 ， 或 者 是 有 着 七 层 负 载 均衡 能 力 的 
Ingress 资 源 。 

















6.1 Service 资 源 及 其 实现 模型 


Service 是 Kubernetes 的 核心 资源 类 型 之 一 ， 通 各 可 看 作 微 服务 的 一 
种 实现 。 事 实 上 它 是 一 种 抽象 : 通过 规则 定义 出 由 多 个 Pod 对 象 组 合 而 
成 的 逻辑 集合 ， 以 及 访问 这 组 Pod 的 策略 。Service 关 联 Pod 资 源 的 规则 要 
借助 于 标签 选择 器 来 完成 ， 这 一 点 类 似 于 第 5 章 讲 到 的 Pod 控 制 右 。 


6.1.1 Service 资 源 概述 


由 Deployment 等 控制 器 管理 的 Pod 对 象 中 断后 会 由 新 建 的 资源 对 象 
所 取代 ， 而 扩 缩 容 后 的 应 用 则 会 带 来 Pod 对 象 群体 的 变动 ， 随 之 变化 的 
还 有 Pod 的 IP 地 址 访问 接口 等 ， 这 也 是 编排 系统 之 上 的 应 用 程序 必然 要 
面临 的 问题 。 例 如 ， 当 图 6-1 中 的 Nginx Pod 作 为 客户 端 访问 tomcat Pod 中 
的 应 用 时 ， 卫 的 变动 或 应 用 规模 的 缩减 会 导致 客户 端 访 问 错误 ， 而 Pod 
规模 的 扩容 又 会 使 得 客户 端 无 法 有 效 地 使 用 新 增 的 Pod 对 象 ， 从 而 影响 
达成 规模 扩展 之 目的 。 为 此 ，Kubernetes 特 地 设计 了 Service 资 源 来 解决 


此 类 问题 。 
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图 6-1 Pod 及 其 客户 端 示例 


Service 资 源 基 于 标签 选择 器 将 一 组 Pod 定 义 成 一 个 逻辑 组 合 ， 并 通 
过 自己 的 IP 地 址 和 端口 调度 代理 请 求 至 组 内 的 Pod 对 象 之 上 ， 如 图 6-2 所 
示 ， 它 向 客户 端 隐藏 了 真实 的 、 处 理 用 户 请 求 的 Pod 资 源 ， 使 得 客户 端 
的 请 求 看 上 去 就 像 是 由 Service 直 接 处 理 并 进行 响应 的 一 样 。 
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图 6-2 ”Kubernetes Service 资 源 模型 示意 图 


Service 对 象 的 IP 地 址 也 称 为 Cluster IP， 它 位 于 为 Kubernetes 集 群 配 
置 指定 专用 IP 地 址 的 范围 之 内 ， 而 且 是 一 种 虚拟 下地 址 ， 它 在 Service 对 
象 创建 后 即 保 持 不 变 ， 并 且 能 够 被 同一 集群 中 的 Pod 资 源 所 访问 。 
Service 端 口 用 于 接收 客户 端 请 求 并 将 其 转发 至 其 后 端的 Pod 中 应 用 的 相 
应 端口 之 上 ， 因 此 ， 这 种 代理 机 制 也 称 为 “端口 代理 ”(port proxy) 或 四 
层 代理 ， 它 工作 于 TCP/IP 协 议 栈 的 传输 层 。 


通过 其 标签 选择 器 匹配 到 的 后 端 Pod 资 源 不 止 一 个 时 ，Service 资 源 
能 够 以 负载 均衡 的 方式 进行 流量 调度 ， 实 现 了 请 求 流量 的 分 发 机 制 。 
Service 与 Pod 对 象 之 间 的 关联 关系 通过 标签 选择 堪 以 松 耦 合 的 方式 建 
立 ， 它 可 以 先 于 Pod 对 象 创建 而 不 会 发 生 错 误 ， 于 是 ， 创 建 Service 与 Pod 
资源 的 任务 可 由 不 同 的 用 户 分别 完 成 ， 例 如 ， 服 务 架构 的 设计 和 创建 由 
运 维 工程 师 进 行 ， 而 填充 其 实现 的 Pod 资 源 的 任务 则 可 交 由 开发 者 进 
行 。Service、 控 制 器 与 Pod 之 间 的 天 系 如 图 6-3 所 示 。 
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图 6-3 Service、 控 制 器 与 Pod 


Service 资 源 会 通过 API Server 持 续 监 视 着 〈watch) 标签 选择 器 匹配 
到 的 后 端 Pod 对 象 ， 并 实时 跟踪 各 对 象 的 变动 ， 例 如 ， 卫 地 址 变动 、 对 
象 增 加 或 减少 等 。 不 过 ， 需 要 特别 说 明 的 是 ，Service 并 不 直接 链接 至 
Pod 对 象 ， 它 们 之 间 还 有 一 个 中 间 层 一 Endpoints 资 源 对 象 ， 它 是 一 个 由 
IP 地 址 和 端口 组 成 的 列表 ， 这 些 IP 地 址 和 端口 则 来 自 于 由 Service 的 标签 
选择 器 匹配 到 的 Pod 资 源 。 这 也 是 很 多 场景 中 会 使 用 *Service 的 后 端 端 
点 ”(Endpoints) 这 一 术语 的 原因 。 默 认 情 况 下 ， 创 建 Service 资 源 对 象 
时 ， 其 关联 的 Endpoints 对 象 会 自动 创建 。 








6.1.2 ”虚拟 IP 和 服务 代理 


简单 来 讲 ， 一 个 Service 对 象 就 是 工作 节点 上 的 一 些 iptables 或 ijpvs 规 
则 ， 用 于 将 到 达 Service 对 象 耻 地 址 的 流量 调度 转发 至 相应 的 Endpoints 对 
象 指 问 的 IP 地 址 和 端口 之 上 。 工 作 于 每 个 工作 节点 的 kube-proxy 组 件 通 
过 API Server 持 续 监 控 着 各 Service 及 与 其 关联 的 Pod 对 象 ， 并 将 其 创建 或 
变动 实时 反映 至 当前 工作 节点 上 相应 的 iptables 或 ipvs 规 则 上 。 客 户 端 、 
Service 及 其 Pod 对 象 的 关系 如 图 6-4 所 示 。 








名 提示 。“ Netfilter 是 Linux 内 核 中 用 于 管理 网 络 报 文 的 框架 ， 它 
有 具有 网 络 地 址 转换 CNAT) 、 报 文 改动 和 报 文 过 滤 年 防火 墙 功 能 ， 用 户 
借助 于 用 户 空 间 的 iptables 等 工具 可 按 需 自由 定制 规则 使 用 其 各 项 功能 。 
ipvs 是 借助 于 Netfilter 实 现 的 网 络 请 求 报 文 调度 框架 ， 支 持 rr、wrr、1c、 
wlc、sh、sed 和 nq 等 十 余 种 调度 算法 ， 用 户 空间 的 命令 行 工具 是 
ipvsadm， 用 于 管理 工作 于 ipvs 之 上 的 调度 规则 。 


Service JP 事实 上 是 用 于 生成 iptables 或 ipvs 规 则 时 使 用 的 卫 地 址 ， 它 
仅 用 于 实现 Kubernetes 集 群 网 络 的 内 部 通信 ， 并 且 仅 能 够 将 规则 中 定义 
的 转发 服务 的 请 求 作 为 目标 地 址 予以 啊 应 ， 这 也 是 它 被 称 为 虚拟 IP 的 原 
因 之 一 。kube-proxy 将 请 求 代 理 至 相应 端点 的 方式 有 三 种 : 
userspace 《用 户 空 间 )〉 、iptables 和 ipvs。 


1.userspace 代 理 模 型 


此 处 的 userspace 是 指 Linux 操 作 系 统 的 用 户 空 间 。 这 种 模型 中 ， 
kube-proxy 人 负责 跟踪 API Server 上 Service 和 Endpoints 对 象 的 变动 (创建 或 
移 除 ) ， 并 据 此 调整 Service 资 源 的 定义 。 对 于 每 个 Service 对 象 ， 它 会 随 
机 打开 一 个 本 地 端口 “运行 于 用 户 空 间 的 kube-proxy 进 程 负 责 监 听 ) ， 
任何 到 达 此 代理 端口 的 连接 请 求 都 将 被 代理 至 当前 Service 资 源 后 端的 各 
Pod 对 象 上 ， 人 至 于 会 挑 中 哪个 Pod 对 和 象 则 取决 于 当前 Service 资 源 的 调度 方 
式 ， 默 认 的 调度 算法 是 轮 询 (round-robin) ， 其 工作 逻辑 如 图 6-5 所 示 。 
另外 ， 此 类 的 Service 对 象 还 会 创建 iptables 规 则 以 捕获 任何 到 达 ClusterIP 
和 端口 的 流量 。 在 Kubernetes 1.1 版 本 之 前 ，userspace 是 默认 的 代理 模 
型 。 
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图 6-5 ”userspace 代 理 模 型 
这 种 代理 模型 中 ， 请 求 流量 到 达 内 核 空间 后 经 由 套 接 字 送 往 用 户 空 
间 的 kube-proxy， 而 后 再 由 它 送 回 内 核 空 间 ， 并 调度 至 后 端 Pod。 这 种 方 
式 中 ， 请 求 在 内 核 空间 和 用 户 空间 来 回转 发 必然 会 导致 效率 不 高 。 


2.iptables 代 理 模 型 





同 前 一 种 代理 模型 类 似 ，iptables 代 理 模型 中 ，kube-proxy 负 责 跟踪 
API Server 上 Service 和 Endpoints 对 象 的 变动 (创建 或 移 除 ) ， 并 据 此 做 
出 Service 资 源 定义 的 变动 。 同 时 ， 对 于 每 个 Service， 它 都 会 创建 iptables 
规则 直接 捕获 到 达 ClusterIP 和 Port 的 流量 ， 并 将 其 重 定 癌 至 当前 Service 
的 后 端 ， 如 图 6-6 所 示 。 对 于 每 个 Endpoints 对 象 ，Service 资 源 会 为 其 创 





建 iptables 规 则 并 关联 至 挑选 的 后 端 Pod 资 源 ， 默 认 算 法 是 随机 调度 
Grandom) 。iptables 代 理 模式 由 Kubernetes 1.1 版 本 引入 ， 并 自 1.2 版 开 
始 成 为 默认 的 类 型 。 


在 创建 Service 资 源 时 ， 集 群 中 每 个 节点 上 的 kube-proxy 都 会 收 到 通 
知 并 将 其 定义 为 当前 节点 上 的 iptables 规 则 ， 用 于 转发 工作 接口 接收 到 的 
与 此 Service 资 源 的 ClusterIP 和 端口 的 相关 流量 。 客 户 端 发 来 的 请 求 被 相 
关 的 iptables 规 则 进行 调度 和 目标 地 址 转换 (DNAT) 后 再 转发 至 集群 内 
的 Pod 对 象 之 上 。 


相对 于 用 户 空间 模型 来 说 ，iptables 模 型 无 须 将 流量 在 用 户 空 间 和 内 
核 空间 来 回 切换 ， 因 而 更 加 高 效 和 可 靠 。 不 过 ， 其 缺点 是 iptables 代 理 模 
型 不 会 在 被 挑 中 的 后 端 Pod 资 源 无 啊 应 时 目 动 进行 重 定 同 ， 而 userspace 
模型 则 可 以 。 


3.ipvs 代 理 模 型 


Kubernetes 自 1.9-alpha 版 本 起 引入 了 ipvs 代 理 模 型 ， 且 自 1.11 版 本 起 
成 为 默认 设置 。 此 种 模型 中 ，kube-proxy 跟 踪 API Server 上 Service 和 
Endpoints 对 象 的 变动 ， 据 此 来 调用 netlink 接 口 创建 ipvs 规 则 ， 并 确保 与 
API Server 中 的 变动 保持 同步 ， 如 图 6-7 所 示 。 它 与 iptables 规 则 的 不 同 之 
处 仅 在 于 其 请 求 流 量 的 调度 功能 由 ipvs 实 现 ， 余 下 的 其 他 功能 仍 由 
iptables 完 成 。 
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图 6-6 iptables 代理 模型 
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configure ipvs 


图 6-7 ipvs 代 理 模型 


类 似 于 iptables 模 型 ，ipvs 构 建 于 netfilter 的 钧 子孙 数 之 上 ， 但 它 使 用 
hash 表 作为 底层 数据 结构 并 工作 于 内 核 空间 ， 因 此 具有 流量 转发 速度 
快 、 规 则 同步 性 能 好 的 特性 。 另 外 ，ipvs 文 持 众多 调度 算法 ， 例 如 ITr、 
lc、dh、sh、sed 和 ng 等。 


6.2 Service 资 源 的 基础 应 用 


Service 资 源 本 号 并 不 提供 任何 服务 ， 真 正 处 理 并 啊 应 客户 端 请 求 的 
是 后 端的 Pod 资 源 ， 这 些 Pod 资 源 通常 由 第 5 章 中 介绍 的 各 类 控制 器 对 象 
所 创建 和 管理 ， 因 此 Service 资 源 通常 要 与 控制 器 资源 《最 为 钊 用 的 控制 
融 之 一 是 Deployment) 协同 使 用 以 完成 应 用 的 创建 和 对 外 发 布 。 





6.2.1 创建 Service 资 源 


创建 Service 对 象 的 常用 方法 有 两 种 ， 一 是 直接 使 用 “kubectl 
expose” 命 令 ， 这 在 前 面 第 3 章 中 已 经 介绍 过 其 使 用 方式 ， 另 一 个 是 使 用 
资源 配置 文件 ， 它 与 此 前 使 用 资源 清单 文件 配置 其 他 资源 的 方法 类 似 。 
定义 Service 资 源 对 象 时 ，spec 的 两 个 较为 常用 的 内 嵌 字 段 分 别 为 selector 
和 ports， 分 别 用 于 定义 使 用 的 标签 选择 器 和 要 暴露 的 端口 。 下 面 的 配置 
清单 是 一 个 Service 资 源 示例 : 














kind: Service 
apiVersion: v1 
metadata: 
name: myapp-svc 
spec: 
selector: 
app: myapp 
ports: 
- protocol: TCP 
port: 80 
targetPort: 80 





Service 资 源 myapp-svc 通 过 标签 选择 器 关联 至 标签 为 “app=myapp” 的 
各 Pod 对 象 ， 它 会 目 动 创建 名 为 myapp-svc 的 Endpoints 资 源 对 象 ， 并 上 自动 
配置 一 个 ClusterIP， 暴 露 的 端口 由 port 字 段 进 行 指 定 ， 后 端 各 Pod 对 象 的 
端口 则 由 targetPort 给 出 ， 也 可 以 使 用 同 port 字 段 的 默认 值 。myapp-svc 创 
建 元 成 后 ， 使 用 下 面 的 命令 即 能 获取 相关 的 信息 输出 以 了 解 资源 的 状 


4UD 





~]$ kubectl1 get Svc myapp-svc 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
myapp-svc ClusterIP 10.107.208.93 <none> 80/TCP 56s 





上 面 命令 中 的 结果 显示 ，myapp-svc 的 类 型 为 默认 的 ClusterIP， 其 使 
用 的 地 址 自动 配置 为 10.107.208.93。 此 类 型 的 Service 对 象 仅 能 通过 此 IP 
地 址 接受 来 自 于 集群 内 的 客户 端 Pod 中 的 请 求 。 若 集群 上 存在 标签 
为 “app=myapp” 的 Pod 资 源 ， 则 它们 会 被 关联 和 创建 ， 作 为 此 Service 对 象 
的 后 端 Endpoint 对 象 ， 并 负责 接收 相应 的 请 求 流量 。 类 似 下 面 的 命令 可 
用 于 获取 Endpoint 资 源 的 端点 列表 ， 其 相关 的 端点 是 由 第 5 章 中 的 








Deployment 控 制 器 创建 的 Pod 对 象 的 套 接 字 信息 组 成 的 : 





~]$ kubectl get endpoints myapp-svc 
NAME ENDPOINTS AGE 
myapp-svc 10.244.1.109:80,10.244.2.249:80,10.244.3.93:80 2m 





名 提示 。 也 可 以 不 为 Service 资 源 指定 .spec.selector 属 性 值 ， 其 关 
联 的 Pod 资 源 可 由 用 户 手动 创建 Endpoints 资 源 进行 定义 。 


Service 对 象 创 建 完成 后 即 可 作为 服务 被 各 客户 端 访问 ， 但 要 真正 啊 
应 这 些 请 求 ， 还 是 要 依赖 于 各 后 端的 资源 对 象 。 


6.2.2” 问 Service 对 象 请 求 服务 


Service 资 源 的 默认 类 型 为 ClusterIP， 它 仅 能 接收 来 自 于 集群 中 的 
Pod 对 象 中 的 客户 端 程序 的 访问 请 求 。 下 面 创建 一 个 专用 的 Pod 对 象 ， 利 
用 其 交互 式 接口 完成 访问 测试 。 为 了 简单 起 见 ， 这 里 选择 直接 创建 一 个 
临时 使 用 的 Pod 对 象 作为 交互 式 使 用 的 客户 端 进行 ， 它 使 用 CirrOS 镜 
像 ， 默 认 的 命令 提示 符 为 “/#": 











“/#": 
~]$ kubectl1 run cirros-$RANDOM --rm -it --image=cirros -- sh 
/ # 





@ CirOS 是 设计 用 来 进行 云 计算 环境 测试 的 Linux 微 型 发 
行 版 ， 它 拥有 HTTP 客 户 端 工具 curl 等 。 


而 后 ， 在 容器 的 交互 式 接口 中 使 用 crul 命 令 对 myapp-svc 服 务 的 
ClusterIP 〈10.107.208.93) 和 Port (80/tcp)〉 发 起 访问 请 求 测试 : 





/# curl http://10.107.208.93:80/ 
Hello MyApp | Version: vi | <a href="hostname.html">Pod Name</a> 





myapp 容 器 中 的 “/hostname.html” 页 面 能 够 输出 当前 容器 的 主机 名 ， 
可 反复 癌 myapp-svc 的 此 URL 路 径 发 起 多 次 请 求 以 验证 其 调度 的 效果 : 





/# for loop in 1 2 3 4; do curl http://10.107.208.93:80/hostname.html; done 
deploy-myapp-86b4b8c75d-rbhf1l 
deploy-myapp-86b4b8c75d-mhbkd 
deploy-myapp-86b4b8c75d-xk8qb 





当前 Kubernetes 集 群 的 Service 代 理 模 式 为 iptables， 它 默认 使 用 随机 
调度 算法 ， 因 此 Service 会 将 客户 端 请 求 随机 调度 至 与 其 关联 的 某 个 后 端 
Pod 资 源 上 。 命 令 取 样 次 数 越 大 ， 其 调度 效果 也 越 接 近 于 算法 的 目标 效 
果 。 





6.2.3 Service 会 话 粘性 


Service 资 源 还 支持 Session affinity 〈 粘 性 会 话 或 会 话 粘 性 ) 机 制 ， 
它 能 够 将 来 自 同一 个 客户 问 的 请 求 始 终 转 发 至 同一 个 后 端的 Pod 对 象 ， 
这 意味 关 它 会 影响 调度 算法 的 流量 分 发 功用 ， 进 而 降低 其 负载 均衡 的 效 
末 。 因 此 ， 当 客户 端 访 问 Pod 中 的 应 用 程序 时 ， 如 果 有 基于 客户 端 屿 份 
保存 某 些 私有 信息 ， 并 基于 这 些 私有 信息 妃 踪 用 户 的 活动 等 一 类 的 需求 
时 ， 那 么 应 该 启用 session affinity 机 制 | 。 


Session affinity 的 效果 仅 会 在 一 定时 间 期 限 内 生效 ， 默 认 值 为 10800 
秒 ， 超 出 此 时 长 之 后 ， 客 户 端的 再 次 访问 会 被 调度 算法 重新 调度 。 男 
外 ，Service 资 源 的 Session affinity 机 制 仅 能 基于 客户 端 耻 地 址 识别 客户 端 
身份 ， 它 会 把 经 由 同一 个 NAT 服 务 器 进行 源 地 址 转换 的 所 有 客户 端 识别 
为 同一 个 客户 端 ， 调 度 粒度 粗糙 旦 效果 不 佳 ， 因 此 ， 实 践 中 并 不 推荐 使 
用 此 种 方法 实现 粘性 会 话 。 此 节 仅 用 于 为 读者 介绍 其 功能 及 实现 。 











Service 资 源 通过 .spec.sessionAffinity 和 .spec.sessionAffinityConfig 两 
A 字段 配置 粘 性 会 话 。spec.sessionAffinity 字 段 用 于 定义 要 使 用 的 粘性 会 
话 的 类 型 ， 它 仅 支 持 使 用 “None” 和 “ClientIP” 两 种 属性 值 。 


.None: 不 使 用 sessionAffinity， 默 认 值 。 


ClientIP: 基于 客户 端 卫 地 址 识别 客户 端 身份 ， 把 来 自 同一 个 源 了 
地 址 的 请 求 始终 调度 至 同一 个 Pod 对 象 。 


在 启用 粘性 会 话机 制 时 ，.spec.sessionAffinityConfig 用 于 配置 其 会 话 
保持 的 时 长 ， 它 是 一 个 般 套 字段 ， 使 用 格式 如 下 所 示 ， 其 可 用 的 时 长 范 
围 为 “1 一 86400”， 默 认为 10800 秒 : 











spec: 
sessionAffinity: ClientIP 
sessionAffinityConfig: 
clientIP: 
timeoutSeconds: <integer> 





例如 ， 其 于 默认 的 10800 秒 的 超时 时 长 ， 使 用 下 面 的 命令 修改 此 前 
的 myapp-svc 使 用 Session affinity 机 制 |]: 





~]$ kubect1 patch services myapp-Svc -p '{"spec": {"sessionAffinity": "ClientIP"}}' 
service "myapp-svc" patched 








而 后 再 次 于 交互 式 客户 端 内 测试 其 访问 效果 即 可 验证 其 会 话 粘 性 效 





/# for loop in1234; do curl http://10.107.208.93:80/hostname.html; done 
deploy-myapp-86b4b8c75d-rbhf1l 
deploy-myapp-86b4b8c75d-rbhf1l 
deploy-myapp-86b4b8c75d-rbhf1l 





测试 完成 后 ， 为 了 保证 本 章 后 续 的 其 他 使 用 效果 测试 不 受 其 影响 ， 
建议 将 其 关闭 。 当 然 ， 用 户 也 可 以 使 用 “kubectl edit” 命 令 直 接 编辑 活动 
Service 对 象 的 配置 清单 。 


6.3 ”服务 发 现 


微服 务 意味 着 存在 更 多 的 独立 服务 ， 但 它们 并 非 独 立 的 个 体 ， 而 是 
存在 着 复杂 的 依赖 关系 有 旦 彼此 之 间 通 常 需要 进行 非常 频繁 地 交互 和 通信 
的 群体 。 然 而 ， 建 立 通 信之 前 ， 服 务 和 服务 之 间 该 如 何 获知 彼此 的 地 址 
呢 ? 在 Kubernetes 系 统 上 ，Service 为 Pod 中 的 服务 类 应 用 提供 了 一 个 稳定 
的 访问 入 口 ， 但 Pod 客 户 端 中 的 应 用 如 何 得 知 茶 个 特定 Service 资 源 的 人 P 
和 端口 呢 ? 这 个 时 候 就 需要 引入 服务 发 现 〈Service Discovery) 的 机 
制 | 。 








6.3.1 服务 发 现 概 述 


简单 来 次 ， 服 务 发 现 束 是 服务 或 者 应 用 之 间 互 相 定位 的 过 程 。 不 
过 ， 服 务 发 现 并 非 新 概念 ， 传 统 的 单 体 应 用 架构 时 代 也 会 用 到 ， 只 不 过 
单 体 应 用 的 动态 性 不 强 ， 更 新 和 重新 发 布 的 频 度 较 低 ， 通 常 以 月 甚至 以 
年 计 ， 基 本 上 不 会 进行 目 动 伸缩 ， 因 此 服务 发 现 的 概念 无 须 显 性 强调 。 
在 传统 的 单 体 应 用 网 络 位 置 发 生变 化 时 ， 由 IT 运 维 人 员 手 工 更 新 一 下 相 
关 的 配置 文件 基本 上 就 能 解决 问题 。 但 在 微服 务 应 用 场景 中 ， 应 用 被 拆 
分 成 众多 的 小 服务 ， 它 们 按 需 创建 且 变 动 频繁 ， 配 置信 息 基 本 无 法 事先 
Oe 0 
随 之 凸显 。 


服务 发 现 机 制 的 基本 实现 ， 一 般 是 事先 部 普 好 一 个 网 络 位 置 较为 稳 
定 的 服务 注册 中 心 〈 也 称 为 服务 总 线 ) ， 服 务 提 供 者 《服务 端 ) 向 注册 
中 心 注册 自己 的 位 置信 息 ， 并 在 变动 后 及 时 予以 更 新 ， 相 应 地 ， 服 务 消 
费 者 则 周期 性 地 从 注册 中 心 获取 服务 提供 者 的 最 新 位 置信 息 从 而 “发 
现 ” 要 访问 的 目标 服务 资源 。 复 杂 的 服务 发 现 机 制 还 能 够 让 服务 提供 者 
提供 其 描述 信息 、 状 态 信息 及 资源 使 用 信息 等 ， 以 供 消 费 者 实现 更 为 复 
杂 的 服务 选择 逻辑 。 


实践 中 ， 根 据 服 务 发 现 过 程 的 实现 方式 ， 服 务 发 现 还 可 分 为 两 种 类 
型 : 客户 喘 发 现 和 服务 端 及 现 。 


客户 端 发 现 : 由 客户 端 到 服务 注册 中 心 发 现 其 依赖 到 的 服务 的 相 
天 信息 ， 因 此 ， 它 需要 内 置 特 定 的 服务 发 现 程序 和 发 现 过 辑 。 


服务 端 发 现 ， 这 种 方式 需要 额外 用 到 一 个 称 为 中 央 路 由 器 或 服务 
均衡 器 的 组 件 ， 服 务 消费 者 将 请 求 发 往 中 央 路 由 需 或 者 负载 均衡 器， 由 
它们 负责 得 询 服务 注册 中 心 获取 服务 提供 者 的 位 置信 息 ， 并 将 服务 消费 
者 的 请 求 转发 给 服务 提供 者 。 


由 此 可 见 ， 服 务 注册 中 心 是 服务 发 现 得 以 沙 地 的 核心 组 件 。 事 实 
上 ，DNS 可 以 算是 最 为 原始 的 服务 发 现 系 统 之 一 ， 不 过 ， 在 服务 的 动态 
性 很 强 的 场景 中 ，DNS 记 录 的 传播 速度 可 能 会 跟 不 上 服务 的 变更 速度 ， 
因此 它 并 不 适用 于 微服 务 环境 。 男 外 ， 传 统 实践 中 ， 和 常见 的 服务 注册 中 
心 是 ZooKeeper 和 etcd 等 分 布 式 键 值 存储 系统 ， 不 过 ， 它 们 只 能 提供 基本 

















的 数据 存储 功能 ， 距 离 实现 完整 的 服务 发 现 机 制 还 有 大 量 的 二 次 开发 任 
务 需 要 完成 。 男 外， 它们 更 注重 数据 的 一 致 性， 这 与 有 大 更 局 的 服务 可 
用 性 要 求 的 微服 务 发 现场 景 中 的 需求 不 太 相 符 。 


Netflix 的 Eureka 是 目前 较为 流行 的 服务 发 现 系统 之 一 ， 它 是 专门 开 
发 用 来 实现 服务 发 现 的 系统 ， 以 可 用 性 目的 为 先 ， 可 以 在 多 种 故障 期 间 
保持 服务 发 现 和 服务 注册 的 功能 可 用 ， 其 设计 原则 亲 从 “存在 少量 的 错 
误 数 据 ， 忌 比 完全 不 可 用 要 好 ”。 男 一 个 同 级 别 的 实现 是 Consul， 它 是 
由 HashiCorp 公 司 提供 的 商业 产品 ， 不 过 该 公司 还 提供 了 一 个 开源 基础 
版 本 。 它 于 服务 发 现 的 基础 功能 之 外 还 提供 了 多 数据 中 心 的 部 普 能 力 等 
一 众 出 色 的 特性 。 


尽管 传统 的 DNS 系统 不 适 于 微服 务 环 境 中 的 服务 发 现 ， 但 SkyDNS 
项 目 〈 后 来 称 kubedns) 却 是 一 个 有 趣 的 实现 ， 它 结合 了 古老 的 DNS 技 
术 和 时 比 的 Go 语言 、Raft 算 法 ， 并 构建 于 etcd 存 储 系 统 之 上 ,为 
Kubernetes 系 统 实现 了 一 种 服务 发 现 机 制 。Service 资 源 为 Kubernetes 提 供 
了 一 个 较为 稳定 的 抽象 层 ， 这 有 点 类 似 于 服务 端 发 现 的 方式 ， 于 是 也 整 
不 存在 DNS 服务 的 时 间 窗 口 的 问题 。 


Kubernetes 目 1.3 版 本 开始 ， 其 用 于 服务 发 现 的 DNS 更 新 为 了 
kubeDNS， 而 类 似 的 另 一 个 基于 较 新 的 DNS 的 服务 发 现 项 目 是 由 
CNCF (Cloud Native Computing Foundation ) 孵化 的 CoreDNS， 它 基于 
Go 语言 开发 ， 通 过 串 接 一 组 实现 DNS 功能 的 插件 的 插件 链 进 行 工 作 。 
自 Kubernetes 1.11 版 本 起 ，CoreDNS 取 代 kubeDNS 成 为 默认 的 DNS 附 
件 。 不 过 ，Kubernetes 依 然 文 持 使 用 环境 变量 进行 服务 发 现 。 














6.3.2 ”服务 友 现 方式 ， 环境 变量 


创建 Pod 资 源 时 ，kubelet 会 将 其 所 属 名 称 空间 内 的 每 个 活动 的 
Service 对 象 以 一 系列 环境 变量 的 形式 注入 其 中 。 它 文 持 使 用 Kubernetes 
Service 环 境 变量 以 及 与 Docker 的 links 兼 容 的 变量 。 


(1) Kubernetes Service 环 境 变 量 
Kubernetes 为 每 个 Service 资 源 生成 包括 以 下 形式 的 环境 变量 在 内 的 
一 系列 环境 变量 ， 在 同一 名 称 空 间 中 创建 的 Pod 对 象 都 会 自动 拥有 这 些 
变量 。 
'{SVCNAME)}) SERVICE _ HOST 


'{SVCNAME}) SERVICE_PORT 


Os 如 果 SVCNAME 中 使 用 了 连接 线 ， 那 么 Kubernetes 会 在 
定义 为 环境 变量 时 将 其 转换 为 下 划 线 。 


(2) Docker Link 形 式 的 环境 变量 


Docker 使 用 --link 选 项 实现 容器 连接 时 所 设置 的 环境 变量 形式 ， 具 体 
使 用 方式 请 参考 Docker 的 相关 文档 。 在 创建 Pod 对 象 时 ，Kubernetes 也 会 
将 与 此 形式 兼容 的 一 系列 环境 变量 注入 Pod 对 象 中 。 


例如 ， 在 Service 资 源 myapp-svc 创 建 后 创建 的 Pod 对 象 中 查看 可 用 的 
环境 变量 ， 其 中 以 MYAPP_SVC_SERVICE 开 头 的 表示 Kubernetes 
Service 环 境 变 量 ， 名 称 中 不 包含 “SERVICE” 字 符 串 的 环境 变量 为 Docker 
Link 形 式 的 环境 变量 : 





/ # printenv | grep MYAPP 
MYAPP_SVC_PORT_80_TCP_ADDR=10.107.208.93 
MYAPP_SVC_PORT_80_TCP_PORT=80 
MYAPP_SVC_PORT_80_TCP_PROTO=tcp 
MYAPP_SVC_PORT_80_TCP=tcp://10.107.208.93:80 
MYAPP_SVC_SERVICE_HOST=10.107.208.93 
MYAPP_SVC_SERVICE_PORT=80 
MYAPP_SVC_PORT=tcp://10.107.208.93:80 

















基于 环境 变量 的 服务 发 现 其 功能 简单 、 易 用 ， 但 存在 一 定 的 局 限 ， 
例如 ， 仅 有 那些 与 创建 的 Pod 对 象 在 同一 名 称 空间 中 且 事 先 存 在 的 
Service 对 象 的 信息 才 会 以 环境 变量 的 形式 注入 ， 那 些 处 于 非 同 一 名 称 空 
间 ， 或 者 是 在 Pod 资 源 创 建 之 后 才 创建 的 Service 对 象 的 相关 环境 变量 则 
不 会 被 添加 。 笠 而， 基于 DNS 的 发 现 机 制 并 不 存在 此 类 限制 。 











6.3.3 ClusterDNS 和 服务 发 现 


Kubernetes 系 统 之 上 用 于 名 称 解 析 和 服务 发 现 的 ClusterDNS 是 集群 
的 核心 附件 之 一 ， 集 群 中 创建 的 每 个 Service 对 象 ， 都 会 由 其 目 动 生成 相 
关 的 资源 记录 。 默 认 情 况 下 ， 集 群 内 各 Pod 资 源 会 上 自动 配置 其 作为 名 称 
解析 服务 器 ， 并 在 其 DNS 搜 索 列表 中 包含 它 所 属 名 称 空间 的 域名 后 级 。 

无 论 是 使 用 kubeDNS 还 是 CoreDNS， 它 们 提供 的 基于 DNS 的 服务 发 
现 解决 方案 都 会 负责 解析 以 下 资源 记录 (Resource Record) 类 型 以 实现 
服务 发 现 。 


(1) 拥有 ClusterIP 的 Service 资 源 ， 需 要 具有 以 下 类 型 的 资源 记 











孙 。 
:A 记录 : <service>.<ns>.svc.<zone>. <ttl> IN A <cluster-ip> 


:SRV 记 录 : _<port>._<proto>.<service>.<ns>.svc.<zone>. <ttl> IN 
SRV <weight> <priority> <port-number> <service>.<ns>.svc.<zone> 


:PTR 记 了 录 : <d>.<c>.<b>.<a>.in-addr.arpa. <ttl> IN PTR <service>. 
<ns>.svc.<zone> 


(2) Headless 类 型 的 Service 资 源 ， 需 要 具有 以 下 类 型 的 资源 记录 。 





:A 记录 : <service>.<ns>.svc.<zone>. <ttl> IN A <endpoint-ip> 


:SRV 记 录 : _<port>._<proto>.<service>.<ns>.svc.<zone>. <ttl> IN 
SRV <weight> <priority> <port-number> <hostname>.<service>.<ns>.svc. 
<zone> 


:PTR 记 录 : <d>.<c>.<b>.<a>.in-addr.arpa. <ttl> IN PTR <hostname>. 
<service>.<ns>.svc.<zone> 


(3) ExternalName 类 型 的 Service 资 源 ， 需 要 具有 CNAME 类 型 的 资 
源 记 录 。 


'CNAME 记 录 : <service>.<ns>.svc.<zone>. <ttl> IN CNAME 


<exthame> 


名 称 解析 和 服务 发 现 是 Kubernetes 系 统 许多 功能 得 以 实现 的 基础 服 
务 ， 它 通常 是 集群 安装 完成 后 应 该 立即 部 署 的 附加 组 件 。 使 用 kubeadm 
初始 化 一 个 集群 时 ， 它 甚至 会 自动 进行 部 署 。 


6.3.4 服务 发 现 方式 ， DNS 


创建 Service 资 源 对 象 时 ，ClusterDNS 会 为 它 自动 创建 资源 记录 用 于 
名 称 解析 和 服务 注册 ， 于 是 ，Pod 资 源 可 直接 使 用 标准 的 DNS 名 称 来 访 
问 这 些 Service 资 源 。 每 个 Service 对 象 相 关 的 DNS 记录 包含 如 下 两 个 。 


{SVCNAME}.{NAMESPACE}.{CLUSTER_ DOMAIN} 
‘{SVCNAME}.{NAMESPACE}.svc.{CLUSTER_ DOMAIN} 


另外 ， 在 前 面 第 2 章 的 部 晋 参 数 中 , “--cluster-dns” 指 定 了 集群 DNS 
服务 的 工作 地 址 ，“--cluster-domain” 定 义 了 集群 使 用 的 本 地 域名 ， 
此 ， 系 统 初 始 化 时 默认 会 将 “cluster.local.” 和 主机 所 在 的 域 “ilinux.io.” 作 
为 DNS 的 本 地 域 使 用 ， 这 些 信息 会 在 Pod 创 建 时 以 DNS 配置 的 相关 信息 
注入 它 的 /etc/resolv.conf 配 置 文件 中 。 例 如 ， 在 此 前 创建 的 用 于 交互 式 
Pod 资 源 的 客户 端 中 查看 其 配置 ， 命 令 如 下 : 








/# cat /etc/resolv.conf 
nameserver 10.96.0.10 
search default.svc.cluster.local svc.cluster.local cluster.local ilinux.io 








上 述 search 参 数 中 指定 的 DNS 各 搜索 域 ， 是 以 次 序 指定 的 几 个 域名 
后 经， 具体 如 下 所 示 。 


{NAMESPACE}.svc.{CLUSTER DOMAIN;}: 如 
default.svc.cluster.local 。 


:svC.{CLUSTER DOMAIN}: 如 svc.cluster.local 。 
.{CLUSTER_DOMAIN}+:， 如 cluster.local 。 
'{WORK NODE _ DOMAINT: nilinux.io。 


例如 ， 在 此 前 创建 的 用 于 交互 式 Pod 客 户 端 中 尝试 请 求解 析 myapp- 
svc 的 相关 DNS 记 录 : 





/ # nslookup myapp-svc.default 
Server: 10.96.0.10 
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.1local 


Name: myapp-svc 
Address 1: 10.107.208.93 myapp-svc.default.svc.cluster.1local 








解析 时 ，“myapp-svc” 服 务 名 称 的 搜索 次 序 依次 是 
default.svc.cluster.local 、svc.cluster.local、cluster.local 和 ilinux.io， 因 此 其 
于 DNS 的 服务 发 现 不 受 Service 资 源 所 在 的 名 称 空 间 和 创建 时 间 的 限制 。 
0 解析 结果 也 正 是 默认 的 default 名 称 空 间 中 创建 的 myapp-svc 服 务 的 
IP 地 址 。 


6.4 服务 雄 露 


Service 的 IP 地 址 仅 在 集群 内 可 达 ， 然 而 ， 总 会 有 些 服务 需要 暴露 到 
外 部 网 络 中 接受 各 类 客户 端的 访问 ， 例 如 分 层 架 构 应 用 中 的 前 端 Web 应 
用 程序 等 。 此 时 ， 就 需要 在 集群 的 边缘 为 其 添加 一 层 转发 机 制 ， 以 实现 
将 外 部 请 求 流量 接 入 到 集群 的 Service 资 源 之 上 ， 这 种 操作 也 称 为 发 布 服 
务 到 外 部 网 络 中 。 


6.4.1 Service 类 型 


Kubernetes 的 Service 共 有 四 种 类 型 : ClusterIP、NodePort、 
LoadBalancer 和 ExternalName。 


“ClusterIP: 通过 集群 内 部 IP 地 址 暴露 服务 ， 此 地 址 仪 在 集群 内 部 可 
达 ， 而 无 法 被 集群 外 部 的 客户 端 访问 ， 如 图 6-8 所 示 。 此 为 默认 的 


Service 类 型 。 


.NodePort: 这 种 类 型 建立 在 ClusterIP 类 型 之 上 ， 其 在 每 个 节点 的 IP 
地 址 的 某 静 态 端口 (NodePort) 姑 露 服务 ， 因 此 ， 它 依然 会 为 Service 分 
配 集群 IP 地 址 ， 并 将 此 作为 NodePort 的 路 由 目标 。 简 单 来 说 ，NodePort 
类 型 就 是 在 工作 节点 的 耳 地 址 上 选择 一 个 端口 用 于 将 集群 外 部 的 用 户 请 
求 转发 至 目标 Service 的 ClusterITP 和 Port， 因 此 ， 这 种 类 型 的 Service 既 可 
如 ClusterIP 一 样 受到 集群 内 部 客户 端 Pod 的 访问 ， 也 会 受到 集群 外 部 客 
户 端 通过 套 接 字 <NodeIP>: <NodePort> 进 行 的 请 求 。 
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图 6-8 ”NodePort Service 类 型 


.LoadBalancer: 这 种 类 型 建构 在 NodePort 类 型 之 上 ， 其 通过 cloud 
provider 提 供 的 负载 均衡 强 将 服务 其 露 到 集群 外 部 ， 因此 LoadBalancer 一 
样 具 有 NodePort 和 ClusterIP。 简 而 言 之 ， 一 个 LoadBalancer 类 型 的 
Service 会 指 问 关联 至 Kubernetes 集 群 外 部 的 、 切 实 存在 的 某 个 负载 均衡 
设备 ， 该 设备 通过 工作 节点 之 上 的 NodePort 向 集群 内 部 发 送 请 求 流量 ， 
如 图 6-9 所 示 。 例 如 Amazon 云 计算 环境 中 的 ELB 实 例 即 为 此 类 的 负载 均 
衡 设备 。 此 类 型 的 优势 在 于 ， 它 能 够 把 来 自 于 集群 外 部 客户 端的 请 求 调 
度 至 所 有 节点 (或 部 分 节点 ) 的 NodePort 之 上 ， 而 不 是 依赖 于 客户 端 自 
点 ， 从 而 避免 了 因 客 户 端 指定 的 节点 故障 而 导致 的 
月 \ 可 


:ExternalName: 其 通过 将 Service 映 射 至 由 externalName 字 段 的 内 容 
指定 的 主机 名 来 暴露 服务 ， 此 主机 名 需要 被 DNS 服务 解析 至 CNAME 类 
型 的 记录 。 换 言 之 ， 此 种 类 型 并 非 定 义 由 Kubernetes 集 群 提 供 的 服务 ， 
而 是 把 集群 外 部 的 某 服 务 以 DNS CNAME 记 录 的 方式 映射 到 集群 内 ， 从 











而 让 集群 内 的 Pod 资 源 能 够 访问 外 部 的 Service 的 一 种 实现 方式 ， 如 图 6- 
10 所 示 。 因 此 ， 这 种 类 型 的 Service 没 有 ClusterIP 和 NodePort， 也 没有 标 
签 选 择 右 用 于 选择 Pod 资 源 ， 因 此 也 不 会 有 Endpoints 存 在 。 


前 面 章 节 中 创建 的 myapp-svc 即 为 默认 的 ClusterIP 类 型 Service 资 源 ， 
它 仅 能 接收 来 自 于 集群 中 的 Pod 对 象 中 的 客户 端 程序 的 访问 请 求 。 如 知 
需要 将 Service 资 源 发 布 至 网 络 外 部 ， 应 该 将 其 配置 为 NodePort 或 
LoadBalancer 类 型 ， 而 知 要 把 外 部 的 服务 发 布 于 集群 内 容 供 Pod 对 象 使 
用 ， 则 需要 定义 一 个 ExternalName 类 型 的 Service 资 源 。 如 若 使 用 kube- 
dns， 那 么 这 种 类 型 的 实现 将 依赖 于 1.7 及 其 以 上 版 本 的 Kubernetes 版 本 。 
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图 6-9 LoadBalancer 类 型 的 Service 
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图 6-10 ”ExternalName 类 型 的 Service 


6.4.2 NodePort 类 型 的 Service 资 源 


NodePort 即 节点 Port， 通 稼 在 安装 部 晋 Kubernetes 集 群 系统 时 会 预 留 
一 个 端口 范围 用 于 NodePort， 默 认为 30000 一 32767 之 间 的 端口 。 与 
ClusterIP 类 型 的 可 省 略 .spec.type 属 性 所 不 同 的 是 ， 定 义 NodePort 类 型 的 
Service 资 源 时 ， 需 要 通过 此 属性 明确 指定 其 类 型 名 称 。 例 如 ， 下 面 配置 
清单 中 定义 的 Service 资 源 对 象 myapp-svc-nodeport， 它 使 用 了 NodePort 类 
型 ， 且 人 为 指定 其 节点 端口 为 32223: 








kind: Service 
apiVersion: v1 
metadata: 

name: myapp-Svc-nodeport 

spec: 

type: NodePort 

selector: 
app: myapp 

ports: 

- protocol: TCP 
port: 80 
targetPort: 80 
nodePort: 32223 





实践 中 ， 并 不 或 励 用 户 目 定义 使 用 的 节点 端口 ， 除 非 事 先 能 够 明确 
知道 它 不 会 与 东 个 现存 的 Service 资 源 产 生 冲 突 。 无 论 如 何 ， 只 要 没有 特 
别 需求 ， 留 给 系统 目 动 配置 总 是 较 好 的 选择 。 使 用 创建 命令 创建 上 面 的 
Service 对 象 后 即 可 了 解 其 运行 状态 : 





~]$ kubect1 get services myapp-svc-nodeport 
NAME TYPE CLUSTER- IPEXTERNAL- IP PORT(S) AGE 
myapp-svc-nodeport NodePort 10.109.234.108 <none> 80:32223/TCP 3S 





命令 结果 显示 ，NodePort 类 型 的 Service 资 源 依然 会 被 配置 
ClusterIP， 事 实 上 ， 它 会 作为 节点 从 NodePort 接 入 流量 后 转发 的 目标 地 
址 ， 目 标 端口 则 是 与 Service 资 源 对 应 的 spec.ports.port 属 性 中 定义 的 端 
口 ， 如 图 6-11 所 示 。 
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图 6-11 请 求 流量 转 及 过 程 


因此 ， 对 于 集群 外 部 的 客户 端 来 说 ， 它 们 可 经 由 任何 一 个 节点 的 节 
点 了 了 及 端口 访问 NodePort 类 型 的 Service 资 源 ， 而 对 于 集群 内 的 Pod 客 户 
端 来 说 ， 依 然 可 以 通过 ClusterIP 对 其 进行 访问 。 


6.4.3 ”LoadBalancer 类 型 的 Service 资 源 


NodePort 类 型 的 Service 资 源 虽 然 能 够 于 集群 外 部 访问 得 到 ， 但 外 部 
客户 端 必须 得 事先 得 知 NodePort 和 集群 中 至 少 一 个 节点 的 IP 地 址 ， 且 选 
定 的 节点 发 生 故 障 时 ， 客 户 端 还 得 自行 选择 请 求 访问 其 他 的 节点 。 男 
外 ， 集 群 节点 很 可 能 是 某 IaaS 云 环境 中 使 用 私有 耳 地 址 的 VM， 或 者 是 
IDC 中 使 用 私有 地 址 的 物理 机 ， 这 类 地 址 对 互联 网 客户 端 不 可 达 ， 因 
此 ， 一 般 还 应 该 在 集群 之 外 创建 一 个 具有 公 网 PP 地址 的 负载 均衡 器 ， 由 
它 接 入 外 部 客户 端的 请 求 并 调度 至 集群 节点 相应 的 NodePort 之 上 。 


IaaS 云 计算 环境 通常 提供 了 LBaaS (Load Balancer as a Service) 服 
务 ， 它 允许 租户 动态 地 在 自己 的 网 络 中 创建 一 个 负载 均衡 设备 。 那 些 部 
署 于 此 类 环境 之 上 的 Kubernetes 集 群 在 创建 Service 资 源 时 可 以 直接 调用 
此 接口 按 需 创建 出 一 个 软 负载 均衡 器 ， 而 具有 这 种 功能 的 Service 资 源 即 
为 LoadBalancer 类 型 。 不 过 ， 如 果 Kubernetes 部 署 于 裸 的 物理 服务 器 之 
上 ， 系 统管 理 员 也 可 以 自行 手动 部 署 一 个 负载 均衡 器 〈 推 荐 使 用 元 余 配 
置 ) ， 并 配置 其 将 请 求 流量 调度 至 各 节点 的 NodePort 之 上 即 可 。 


下 面 是 一 个 LoadBalancer 类 型 的 Service 资 源 配 置 清单 ， 奇 Kubernetes 
系统 满足 其 使 用 条 件 ， 即 可 自行 进行 应 用 测试 。 需 要 注意 的 是 ， 有 些 环 
境 中 可 能 还 需要 为 Service 资 源 的 配置 定义 添加 Annotations， 必 要 时 请 上 自 
行 参 考 Kubernetes 文 档 中 的 说 明 : 

















kind: Service 
apiVersion: v1 
metadata: 

name: myapp-svc-1b 

spec: 

type: LoadBalancer 

selector: 
app: myapp 

ports: 

- protocol: TCP 
port: 80 
targetPort: 80 
nodePort: 32223 





进一步 地 ， 在 IaaS 环 境 文 持 手动 指定 IP 地 址 时 ， 用 户 还 可 以 使 
用 .spec.loadBalancerIP 指 定 创建 的 负载 均衡 器 使 用 的 IP 地 址 ， 并 可 使 





用 .spec.loadBalancerSourceRanges 指 定 负 载 均衡 器 允许 的 客户 端 来 源 的 
地 址 范围 。 


6.4.4 ExternalName Service 


ExternalName 类 型 的 Service 资 源 用 于 将 集群 外 部 的 服务 发 布 到 集群 
中 以 供 Pod 中 的 应 用 程序 访问 ， 因 此 ， 它 不 需要 使 用 标签 选择 器 关联 任 
何 的 Pod 对 象 ， 但 必须 要 使 用 spec.externalName 属 性 定义 一 个 CNAME 记 
录用 于 返回 外 部 真正 提供 服务 的 主机 的 别名 ， 而 后 通过 CNAME 记 录 值 
获取 到 相关 主机 的 IP 地 址 。 


下 面 是 一 个 ExternalName 类 型 的 Service 资 源 示例 ， 名 为 external- 
redis-svc， 相 应 的 externalName 为 “redis.ilinux.io”: 





kind: Service 
apiVersion: v1 
metadata: 
name: external-redis-svc 
namespace: default 
spec: 
type: ExternalName 
externalName: redis.ilinux.io 
ports: 
- protocol: TCP 
port: 6379 
targetPort: 6379 
nodePort: 0 
selector: {} 





待 Service 资 源 external-redis-svc 创 建 完 成 后 ， 各 Pod 对 象 即 可 通过 
external-redis-svc 或 其 FQDN 格 式 的 名 称 external-redis- 
svc.default.svc.cluster.local 访 问 相 应 的 服务 。ClusterDNS 会 将 此 名 称 以 
CNAME 格 式 解析 为 .spec.externalName 字 段 中 的 名 称 ， 而 后 通过 DNS 服 
务 将 其 解析 为 相应 的 主机 的 耳 地 址 。 例 如 ， 通 过 此 前 创建 的 交互 Pod 资 
源 客户 端 进行 服务 名 称 解 析 : 





/ # nslookup external-redis-svc 
Server: 10.96.0.10 
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.1local 


Name: external-redis-svc 
Address 1: 45.54.44.100 100.44.54.45.ptr.anycast.net 





由 于 ExternalName 类 型 的 Service 资 源 实现 于 DNS 级 别 ， 客 户 端 将 直 





接 接 入 外 部 的 服务 而 完全 不 需要 服务 代理 ， 因 此 ， 它 也 无 须 配置 
ClusterIP， 此 种 类 型 的 服务 也 称 为 Headless Service。 


6.5 “Headless 类 型 的 Service 资 源 


Service 对 象 隐藏 了 各 Pod 资 源 ， 并 负责 将 客户 端的 请 求 流量 调度 至 
该 组 Pod 对 象 之 上 上。 不过， 偶尔 也 会 存在 这 样 一 类 需求 : 客户 端 需要 直 
接 访问 Service 资 源 后 端的 所 有 Pod 资 源 ， 这 时 就 应 该 同 客 户 端 暴露 每 个 
Pod 资 源 的 人 P 地 址 ， 而 不 再 是 中 间 层 Service 对 象 的 ClusterIP， 这 种 类 型 
的 Service 资 源 便 称 为 Headless Service。 








Headless Service 对 象 没 有 ClusterIP， 于 是 kube-proxy 便 无 须 处 理 此 
类 请 求 ， 也 就 更 没有 了 负载 均衡 或 代理 它 的 需要 。 在 前 端 应 用 拥有 自 有 
的 其 他 服务 发 现 机 制 时 ，Headless Service 即 可 省 去 定义 ClusterIP 的 需 
0 
J 定义 。 


.具有 标签 选择 器 : 端点 控制 器 (Endpoints Controller) 会 在 API 中 
为 其 创建 Endpoints 记 录 ， 并 将 ClusterDNS 服 务 中 的 A 记 录 直 接 解析 到 此 
Service 后 端的 各 Pod 对 象 的 人 P 地 址 上 。 


:没有 标签 选择 器 : 端点 控制 器 〈Endpoints Controller ) 不 会 在 API 
中 为 其 创建 Endpoints 记 录 ，ClusterDNS 的 配置 分 为 两 种 情形 ， 对 
ExternalName 类 型 的 服务 创建 CNAME 记 录 ， 对 其 他 三 种 类 型 来 说 ， 为 
那些 与 当前 Service 共 享 名 称 的 所 有 Endpoints 对 象 创建 一 条 记录 。 





6.5.1 ”创建 Headless Service 资 源 


配置 Service 资 源 配置 清单 和 时， 只 需要 将 ClusterIP 字 上 段 的 值 设 置 
为 “None” 即 可 将 其 定义 为 Headless 类 型 。 下 面 是 一 个 Headless Service 资 
源 配置 清单 示例 ， 它 拥有 标签 选择 器 : 





kind: Service 
apiVersion: v1 
metadata: 
name: myapp-headless-svc 
spec: 
clusterIP: None 
selector: 
app: myapp 
ports: 
- port: 80 
targetPort: 80 
name: httpport 





使 用 资源 创建 命令 “kubectl create” 或 “kubectl apply” 完 成 资源 创建 
后 ， 使 用 相关 的 查看 命令 获取 Service 资 源 的 相关 信息 便 可 以 看 出 ， 它 没 
有 ClusterIP， 不 过 ， 如 果 标 签 选择 器 能 够 罗 配 到 相关 的 Pod 资 源 ， 它 便 
拥有 Endpoints 记 录 ， 这 些 Endpoints 对 象 会 作为 DNS 资源 记录 名 称 myapp- 
headless-svc 查 询 时 的 A 记录 解析 结果 : 





~]$ kubect1 describe svc myapp-headless-svc 


Endpoints: 10.244.1.113:80,10.244.2.13:80,10.244.3.104:80 





6.5.2” Pod 资源 发 现 


根据 Headless Service 的 工作 特性 可 知 ， 它 记录 于 ClusterDNS 的 A 记 
录 的 相关 解析 结果 是 后 端 Pod 资 源 的 IP 地 址 ， 这 就 意味 着 客户 端 通过 此 
Service 资 源 的 名 称 发 现 的 是 各 Pod 资 源 。 下 面 依然 选择 创建 一 个 专用 的 
测试 Pod 对 象 ， 而 后 通过 其 交互 式 接口 进行 测试 : 








~]$ kubectl1 run cirros-$RANDOM --rm -it --image=cirros -- sh 


/ # nslookup myapp-headless-svc 
Server: 10.96.0.10 
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.1local 


Name : myapp-headless-svc 
Address 1: 10.244.2.13 
Address 2: 10.244.1.113 
Address 3: 10.244.3.104 





其 解析 结果 正 是 Headless Service 通 过 标签 选择 器 关联 到 的 所 有 Pod 
资源 的 IP 地 址 。 于 是 ， 客 户 端 向 此 Service 对 象 发 起 的 请 求 将 直接 接 入 到 
Pod 资 源 中 的 应 用 之 上 ， 而 不 再 由 Service 资 源 进行 代理 转发 ， 它 每 次 接 
入 的 Pod 资 源 则 是 由 DNS 服务 器 接收 到 得 询 请 求 时 以 轮 询 (roundrobin) 
的 方式 返回 的 人 P 地 址 。 


6.6 ”Ingress 资 源 


Kubernetes 提 供 了 两 种 内 建 的 云端 负载 均衡 机 制 (cloud load 
balancing) 用 于 发 布 公共 应 用 ， 一 种 是 工作 于 传输 层 的 Service 资 源 ， 它 
实现 的 是 “TCP 负 载 均 衡器 >， 另 一 种 是 mgress 资 源 ， 它 实现 的 
是 “HTTP (S) 负载 均衡 器 ”。 


(1) TCP 负 载 均 衡器 


无 论 是 iptables 还 是 ipvs 模 型 的 Service 资 源 都 配置 于 Linux 内 核 中 的 
Netfilter 之 上 进行 四 层 调度 ， 是 一 种 类 型 更 为 通用 的 调度 器 ， 文 持 调度 
HTTP、MySQL 等 应 用 层 服务 。 不 过 ， 也 正 是 由 于 工作 于 传输 层 从 而 使 
得 它 无 法 做 到 类 似 介 载 HTTPS 中 的 SSL 会 话 等 一 类 操作 ， 也 不 文 持 基于 
URL 的 请 求 调度 机 制 ， 而 且 ，Kubernetes 也 不 支持 为 此 类 负载 均衡 器 配 
置 任何 类 型 的 健康 状态 检查 机 制 。 


(2) HTTP (S) 负载 均衡 器 


HTTP (S) 负载 均衡 器 是 应 用 层 负 载 均 衡 机 制 的 一 种 ， 支 持 根 据 环 
境 做 出 更 好 的 调度 决策 。 与 传输 层 调 度 器 相 比 ， 它 提供 了 诸如 可 自 定义 
URL 映 射 和 TLS 仓 载 等 功能 ， 并 文 持 多 种 类 型 的 后 端 服 务 器 健康 状态 检 
查 机 制 。 








6.6.1 Ingress 和 Ingress Controller 


Kubernetes 中 ，Service 资 源 和 Pod 资 源 的 耳 地址 仅 能 用 于 集群 网 络 内 
部 的 通信 ， 所 有 的 网 络 流 量 都 无 法 罕 透 边界 路 由 器 (Edge Router) 以 实 
现 集群 内 外 通信 。 尽 管 可 以 为 Service 使 用 NodePort 或 LoadBalancer 类 型 
通过 节点 引入 外 部 流量 ， 但 它 依然 是 4 层 流量 转发 ， 可 用 的 负载 均衡 堪 
也 为 传输 层 负载 均衡 机 制 。 


Ingress 是 Kubernetes API 的 标准 资源 类 型 之 一 ， 它 其 实 就 是 一 组 基 
于 DNS 名 称 (host) 或 URL 路 径 把 请 求 转 发 至 指定 的 Service 资 源 的 规 
则 ， 用 于 将 集群 外 部 的 请 求 流 量 转发 至 集群 内 部 完成 服务 发 布 。 然 而 ， 
Ingress 资 源 目 身 并 不 能 进行 “流量 穿 透 >， 它 仅 是 一 组 路 由 规则 的 集合 ， 
这 些 规则 要 想 真 正 发 挥 作 用 还 需要 其 他 功能 的 辅助 ， 如 监听 某 套 接 字 ， 
然后 根据 这 些 规则 的 匹配 机 制 路 由 请 求 流量 。 这 种 能 够 为 mgress 资 源 监 
听 套 接 字 并 转发 流量 的 组 件 称 为 Ingress 控 制 器 (Ingress Controller) 。 








PQ 

(Os 不 同 于 Deployment 控 制 占 等 ，Ingress 控 制 占 并 不 直接 
运行 为 kube-controller-manager 的 一 部 分 ， 它 是 Kubernetes 集 群 的 一 个 重 
要 附件 ， 类 似 于 CoreDNS， 需 要 在 集群 上 单独 部 署 。 


Ingress 控 制 器 可 以 由 任何 具有 反问 代理 (HTTP/HTTPS) 功 能 的 服 
务 程 序 实现 ， 如 Nginx、Envoy、HAProxy、Vulcand 和 Traefik 等 。Ingress 
控制 器 自身 也 是 运行 于 集群 中 的 Pod 资 源 对 象 ， 它 与 被 代理 的 运行 为 Pod 
资源 的 应 用 运行 于 同一 网 络 中 ， 如 图 6-12 中 ingress-nginx 与 podl1、pod3 
等 的 关系 所 示 。 
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图 6-12 Ingress 与 Ingress Controller 


另 一 方面 ， 使 用 Ingress 资 源 进行 流量 分 发 时 ，Ingress 控 制 器 可 基于 
某 Imngress 资 源 定义 的 规则 将 客户 端的 请 求 流 量 直 接 转 发 至 与 Service 对 应 
的 后 端 Pod 资 源 之 上 ， 这 种 转发 机 制 会 绕 过 Service 资 源 ， 从 而 省 去 了 由 
kube-proxy 实 现 的 端口 代理 开销 。 如 图 6-12 所 示 ，Ingress 规 则 需要 由 一 
个 Service 资 源 对 象 辅助 识别 相关 的 所 有 Pod 对 象 ， 但 ingress-nginx 控 制 器 
可 经 由 apiilinux.io 规 则 的 定义 直接 将 请 求 流量 调度 至 pod3 或 pod4， 而 无 
人 WAP 相 关 规则 的 作用 方式 与 此 类 


6.6.2 ”创建 Ingress 资 源 


Ingress 资 源 是 基于 HTTP 虚 拟 主 机 或 URL 的 转发 规则 ， 它 在 资源 配 
置 清 单 的 spec 字 上 段 中 骨 套 了 rules、backend 和 tls 等 字段 进行 定义 。 下 面 的 
示例 中 定义 了 一 个 mgress 资 源 ， 它 包含 了 一 个 转发 规则 ， 把 发 往 
www.ilinux.io 的 请 求 代理 给 名 为 myapp-svc 的 Service 资 源 : 





apiVersion: extensions/vibetal 
kind: Ingress 
metadata: 
name: my-ingress 
annotations: 
kubernetes.io/ingress.class: "nginx" 
spec: 
rules: 
- host: www.ilinux.io 
http: 
paths : 
- backend : 
serviceName: myapp-svc 
servicePort: 80 





上 面 资 源 清 单 中 的 annotations 用 于 识别 其 所 属 的 Ingress 控 制 器 的 类 
别 ， 这 一 点 在 集群 上 部 署 有 多 个 Ingress 控 制 器 时 尤为 重要 。Ingress Spec 
中 的 字段 是 定义 Ingress 资 源 的 核心 组 成 部 分 ， 它 主要 髓 套 如 下 三 个 字 
眉 。 


Tules<Object> : 用 于 定义 当前 Ingress 资 源 的 转发 规则 列表 ; 未 由 
rules 定 义 规 则 ， 或 者 没有 匹配 到 任何 规则 时 ， 所 有 流量 都 会 转发 到 由 
backend 定 义 的 默认 后 端 。 


backend<Object> : 默认 的 后 端 用 于 服务 那些 没有 匹配 到 任何 规则 
的 请 求 ;， 定义 Ingress 资 源 时 ， 人 至 少 应 该 定义 backend 或 rules 两 者 之 一 ; 此 
字段 用 于 让 负载 均衡 器 指定 一 个 全 局 默认 的 后 端 。 

tls<Object> : TLS 配 置 ， 目 前 仅 文 持 通过 默认 问 口 443 提 供 服务 ; 
如 果 要 配置 指定 的 列表 成 员 指 同 了 不 同 的 主机 ， 则 必须 通过 SNI TLS 扩 
展 机 制 来 支持 此 功能 。 


backend 对 象 的 定义 由 两 个 必 选 的 内 骸 字 上 段 组 成 :serviceName 和 











servicePort， 分 别 用 于 指定 流量 转发 的 后 端 目 标 Service 资 源 的 名 称 和 站 
口 O 


rules 对 象 由 一 系列 配置 Ingress 资 源 的 host 规 则 组 成 ， 这 些 host 规 则 用 
于 将 一 个 主机 上 的 某 个 URL 路 径 映 射 至 相关 的 后 端 Service 对 象 ， 它 的 定 
义 格式 如 下 : 





serviceName: <String> 
servicePort: <String> 
path: <String> 





注意 ，.spec.rules.host 属 性 值 目前 不 文 持 使 用 卫 地 址 ， 也 不 文 持 后 
跟 *: PORT 格式 的 端口 号 ， 且 此 字段 值 留 空 表示 通 配 所 有 的 主机 名 。 


tls 对 象 由 两 个 内 藤 字 段 组 成 ， 仅 在 定义 TLS 主 机 的 转发 规则 时 才 需 
要 定义 此 类 对 象 。 

:hosts: 包含 于 使 用 的 TLS 证 书 之 内 的 主机 名 称 字 符 串 列表 ， 因 此 ， 
此 处 使 用 的 主机 名 必须 匹配 tlsSecret 中 的 名 称 。 


secretName: 用 于 引用 SSL 会 话 的 secret 对 象 名 称 ， 在 基于 SNI 实 现 
多 主机 路 由 的 场景 中 ， 此 字段 为 可 选 。 





6.6.3 ”Ingress 资 源 类 型 


基于 HTTP 暴 露 的 每 个 Service 资 源 均 可 发 布 于 一 个 独立 的 FQDN 主 
机 名 之 上 ， 如 “www.ik8s.io”; 也 可 发 布 于 某 主 机 的 URL 路 径 之 上 ， 从 而 
将 它们 整合 到 同一 个 Web 站 点 ， 如 “www.ik8s.io/grafana”。 人 至 于 是 否 需 要 


发 布 为 HTTPS 类 型 的 应 用 则 取决 于 用 户 的 业务 需求 。 
1. 单 Service 资 源 型 Ingress 
暴露 单个 服务 的 方法 有 很 多 种 ， 如 服务 类 型 中 的 NodePort、 


LoadBalancer 和 等 ， 不 过 一 样 可 以 考虑 使 用 Ingress 来 歇 露 服务 ， 此 时 只 雷 
要 为 Ingress 指 定 “default backend” 即 可 。 例 如 下 面 的 示例 : 








apiVersion: extensions/vibeta1 
kind: Ingress 
metadata: 
name: my-ingress 
spec: 
backend: 
serviceName: my-svc 
servicePort: 80 





Ingress 控 制 器 会 为 其 分 配 一 个 IP 地 址 接 入 请 求 流量 ， 并 将 它们 转 至 
示例 中 的 my-svc 后 端 。 


2. 基 于 UREL 路 径 进行 流量 分 发 


垂直 拆 分 或 微服 务 架 构 中 ， 每 个 小 的 应 用 都 有 其 专用 的 Service 资 源 
暴露 服务 ， 但 在 对 外 开放 的 站 点 上 ， 它 们 可 能 是 财经 、 新 闻 、 电 商 、 无 
线 端 或 API 接 口 等 一 类 的 独立 应 用 ， 可 通过 主 域 名 的 URL 路 径 (path) 
分 别 接 入 ， 例 如 ，www.ilinux.io/api 、www.ilinux.io/wap 等 ， 用 于 发 布 
集群 内 名 称 为 API 和 WAP 的 Services 资 源 。 于 是 ， 可 对 应 地 创建 一 个 如 
下 的 Ingress 资 源 ， 它 将 对 www.ilinux.io/api 的 请 求 统统 转发 至 API 
Service 资 源 ， 将 对 www.ilinux.io/wap 的 请 求 转发 至 WAP Service 资 源 : 








apiVersion: extensions/vibeta1 
kind: Ingress 
metadata: 

name: test 


annotations : 
ingress.kubernetes.io/rewrite-target: / 
spec: 
rules: 
- host: www.ilinux.io 
http: 
paths : 
- path: /wap 
backend: 
serviceName: wap 
servicePort: 80 
- path: /api 
backend: 
serviceName: api 
servicePort: 80 





Os 目前 ，ingress-nginx 似 乎 尚且 不 能 很 好 地 支持 基于 
annotations 进 行 URL 上 映射。 这 就 意味 痢 ， 在 ingress-nginx 上 ， 此 项 功能 冲 
且 不 能 使 用 。 有 基体 信息 请 参考 这 个 链接 中 的 讨 


论 ，https://github.com/istio/istio/issues/585 。 
3. 基 于 主机 名 称 的 虚拟 主机 


上 面 类 型 2 中 摘 述 的 需求 ， 也 可 以 将 每 个 应 用 分 别 以 独立 的 FQDN 
主机 名 进行 输出 ， 如 wap.ik8s.io 和 api.ik8s.io， 这 两 个 主机 名 解析 到 
external LB 〈 如 图 6-12 所 示 ) 的 耳 地 址 之 上 ， 分 别 用 于 发 布 集群 内 部 的 
WAP 和 API 这 两 个 Service 资 源 。 这 种 实现 方案 其 实 就 是 web 站 点 部 署 中 
的 “基于 主机 名 的 虚拟 主机 ”， 将 多 个 FQDN 解 析 至 同一 个 下地 址 ， 然 后 
根据 “主机 头 ”(Host header) 进行 转发 。 下 面 是 以 独立 FQDN 主 机 形式 
发 布 服务 的 mgress 资 源 示例 : 











apiVersion: extensions/vibetal 
kind: Ingress 
metadata: 

name: test 
spec: 

rules: 

- host: api.ik8s.io 

http: 

paths : 

- backend: 
serviceName: api 
servicePort: 80 

- host: wap.ik8s.io 
http: 

paths : 

- backend: 
serviceName: wap 


servicePort: 80 





4.TLS 类 型 的 Ingress 资 源 


这 种 类 型 用 于 以 HTTPS 发 布 Service 资 源 ， 基 于 一 个 含有 私 钥 和 证 书 
的 Secret 对 象 《后 面 章节 中 会 详细 讲述 ) 即 可 配置 TLS 协 议 的 mgress 资 
源 ， 目 前 来 说 ，Ingress 资 源 仅 文 持 单 TLS 端 口 ， 并 且 还 会 秋 载 TLS 会 
话 。 在 Ingress 资 源 中 引用 此 Secret 即 可 让 Ingress 控 制 器 加 载 并 配置 为 
HTTPS 服 务 。 


下 面 是 一 个 简单 的 TLS 类 型 的 Ingress 资 源 示例 : 








apiVersion: extensions/vibetal 
kind: Ingress 


metadata: 
name: no-rules-map 
spec: 
tls: 
- SecretName: ikubernetesSecret 
backend: 


serviceName: homesite 
servicePort: 80 


= 


6.6.4 ”部署 Ingress 控 制 器 (Nginx) 


Ingress 控 制 器 自身 是 运行 于 Pod 中 的 容器 应 用 ， 一 般 是 Nginx 或 
Envoy 一 类 的 共有 代理 及 负载 均衡 功能 的 守护 进程 ， 它 监视 着 来 自 于 
API Server 的 Ingress 对 象 状态 ， 并 以 其 规则 生成 相应 的 应 用 程序 专 有 格 
式 的 配置 文件 并 通过 重 载 或 重启 守护 进程 而 使 新 配置 生效 。 例 如 ， 对 于 
Nginx 来 说 ，Ingress 规 则 需要 转换 为 Nginx 的 配置 信息 。 简 单 来 说 ， 
Ingress 控 制 器 其 实 就 是 托管 于 Kubernetes 系 统 之 上 的 用 于 实现 在 应 用 层 
发 布 服务 的 Pod 资 源 ， 它 将 跟踪 Ingress 资 源 并 实时 生成 配置 规则 。 那 
么 ， 同 样 运行 为 Pod 资 源 的 Ingress 控 制 器 进程 又 该 如 何 接 入 外 部 的 请 求 
流量 呢 ? 利用 的 解雇 方案 有 如 下 两 种 。 
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图 6.13 使 用 专用 的 ER 象 为 Ingress 控 制 器 接 入 i 部 汤 认 量 
.以 Deployment 控 制 器 管理 mgress 控 制 器 的 Pod 资 源 ， 并 通过 


NodePort 或 LoadBalancer 类 型 的 Service 对 象 为 其 接 入 集群 外 部 的 请 求 流 
量 ， 这 就 意味 着 ， 定 义 一 个 mgress 控 制 器 时 ， 必 须 在 其 前 端 定 义 一 个 专 
用 的 Service 资 源 ， 如 图 6-13 所 示 。 








.借助 于 DaemonSet 控 制 器 ， 将 Ingress 控 制 器 的 Pod 资 源 各 自 以 单 一 
实例 的 方式 运行 于 集群 的 所 有 或 部 分 工作 节点 之 上 ， 并 配置 这 类 Pod 对 
象 以 hostPort (如 图 6-14a) 或 hostNetwork 〈 如 图 6-14b) 的 方式 在 当前 节 
点 接 入 外 部 流量 。 
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图 6-14 ”以 hostPort 或 hostNetwork 的 方式 为 Ingress 控 制 器 接 入 外 部 流量 


以 ingress-nginx 项 目 为 例 ， 部 署 Ingress Nginx 控 制 占 的 配置 文件 被 切 
割 存放 在 了 多 个 不 同 的 文件 中 ， 并 集中 存储 于 其 源码 deploy 子 目录 下 ， 
同时 ， 为 了 方便 用 户 部 署 ， 它 还 将 所 需 的 资源 全 部 集成 为 一 个 配置 文件 


mandatory.yam!l: 





~]$ kubectl apply -f https://raw.githubusercontent,.com/kubernetes/ingress- 
nginx/master/deploy/mandatory.yaml 





因为 需要 下 载 相 关 的 镜像 文件 ， 因 此 前 面部 普 过 程 中 的 Pod 资 源 的 
创建 需要 等 待 一段 时 间 才 能 完成 ， 共 体 时 长 要 取决 于 网 络 的 可 用 状况 。 
可 使 用 如 下 命令 持续 监控 创建 过 程 ， 待 其 状态 为 "Running” 之 后 即 表 示 
运行 正常: 





~]$ kubectl get pods -n ingress-nginx --watch 


NAME READY STATUS RESTARTS AGE 
default-http-backend-6586bc58b6-cw7c6 1/1 Running 0 3m 
nginx-ingress-controller-7675fd6cdb-kvsh2 1/1 Running 0 3m 





在 线 的 配置 清单 中 采用 了 基于 Deployment 控 制 器 部 署 Ingress Nginx 
的 方式 ， 因 此 接 入 外 部 流量 之 前 还 需要 手动 为 其 创建 相关 的 NodePort 或 
LoadBalancer 类 型 的 Service 资 源 对 象 ， 下 面 的 配置 清单 示例 中 对 类 型 定 
义 了 NodePort， 并 明确 指定 了 易 记 的 端口 和 IP 地 址 ， 以 方便 用 户 使 用 : 








apiVersion: v1 
kind: Service 
metadata: 
name: nginx-ingress-controller 
namespace: ingress-nginx 
spec: 
type: NodePort 
clusterIP: 10.99.99.99 
ports: 
- port: 80 
name: http 
nodePort: 30080 
- port: 443 
name: https 
nodePort: 30443 
selector: 
app.kubernetes.io/name: ingress-nginx 





将 上 面 的 配置 信息 保存 于 文件 中 ， 如 nginx-ingress-service.yaml， 而 
后 执行 如 下 命令 完成 资源 的 创建 。 注 意 ， 其 标签 选择 器 应 该 与 
mandatory.yaml 配 置 清单 中 的 Deployment 控 制 器 nginx-ingress-controller 的 
选择 器 保持 一 致 : 





~]$ kubectl1 apply -f nginx-ingress-service.yaml 





名 注意 ”如 果 读 者 的 集群 运行 支持 LBaaS 的 IaaS 云 环境 ， 则 可 以 
将 其 类 型 指定 为 LoadBalancer， 这 样 直 接 就 有 了 可 用 的 external-LB。 


确认 Service 对 象 nginx-ingress-controller 的 状态 没有 问题 后 即 可 于 集 
群 外 部 对 其 发 起 访问 测试 ， 目 标 URL 为 http://<NodeIP>:30080 
或 http://<NodeIP>:30443 ， 确 认可 接收 到 啊 应 报 文 后 即 表示 Ingress 
Nginx 部 署 完 成 。 不 过 ， 本 示例 中 尚且 缺少 一 个 可 用 的 外 部 负载 均衡 
器 ， 如 图 6-13 中 所 示 的 “external-LB”， 因 此 ， 访 问 测试 时 暂时 还 只 能 使 





用 http://<NodeIp>:<NodePort> 进行 。 


6.7 案例 : 使 用 mgress 发 布 tomcat 


假设 有 这 样 一 套 环境 : Kubernetes 集 群 上 的 tomcat-deploy 控 制 器 生 
成 了 两 个 运行 于 Pod 资 源 中 的 tomcat 实 例 ，tomcat-svc 是 将 它们 统一 暴露 
于 集群 中 的 访问 入 口 。 现 在 需要 通过 Ingress 资 源 将 tomcat-svc 发 布 给 集 
群 外 部 的 客户 问 访 问 。 有 基体 的 需求 和 规划 如 网 6-15 所 示 。 


为 了 便于 读者 理解 ， 下 面 的 测试 操作 过 程 将 把 每 一 步 分 解 开 来 放 在 
单独 的 一 节 中 进行 。 








6.7.1 准备 名 称 空 间 


假设 本 示例 中 创建 的 所 有 资源 都 位 于 新 建 的 testing 名 称 空间 中 ， 与 
其 他 的 资源 在 逻辑 上 进行 隔离 ， 以 方便 管理 。 下 面 的 配置 信息 保存 于 
testing-namespace.yaml 资 源 清单 文件 中 : 
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图 6-15 ”Ingress 发 布 应 用 示例 拓扑 图 
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kind: Namespace 
apiVersion: v1 
metadata: 
name: testing 
labels: 
env: testing 





而 后 运行 创建 命令 完成 资源 的 创建 ， 并 确认 资源 的 存在 : 





~]$ kubectl1 apply -f testing-namespace.yaml 
namespace "testing" created 
~]$ kubectl get namespaces testing 


NAME STATUS AGE 
testing Active 8s 


一 ”_A 


6.7.2 ”部 署 tomcat 实 例 





在 此 示例 中 ，tomcat/v De es 
际 应 用 。 具 体 实 践 中 ， 它 通常 Re 
像 文件 。 下 面 的 配置 清单 使 用 了 Deployment 控 制 器 于 testing 中 部 署 
tomcat 相 关 的 Pod 对 象 ， 它 保存 于 tomcat-deploy.yaml 文 件 中 : 








apiVersion: appSs/Vv1I 
kind: Deployment 
metadata: 
name: tomcat-deploy 
namespace: testing 
spec: 
replicas: 2 
selector: 
matchLabels: 
app: tomcat 
template: 
metadata: 
labels: 
app: tomcat 
spec: 
Containers : 
- _ name: tomcat 
image: tomcat:8.0.50-jre8-alpine 
ports: 
- containerPort: 8080 
name: httpport 
- containerPort: 8009 
name: ajpport 





运行 资源 创建 命令 完成 Deployment 控 制 器 和 Pod 资 源 的 创建 ， 命 令 





~]$ kubectl apply -f tomcat-deploy.yaml 








接着 运行 命令 以 确认 其 成 功 完成 ， 且 各 Pod 已 经 处 于 正常 运行 状态 
中 





~]$ kubect1l get pods -n testing 

NAME READY STATUS RESTARTS AGE 
tomcat-deploy-6cf8468f7f-5d7tb 1/1 Running 0 1m 
tomcat-deploy-6cf8468f7f-9fvxx 1/1 Running 0 1m 





实践 中 ， 如 果 需 要 更 多 的 Pod 资 源 承 载 用 户 访 问 ， 那 么 使 用 
Deployment 控 制 费 的 规模 伸缩 机 制 即 可 完成 ， 或 者 直接 修改 上 面 的 配置 
文件 并 执行 “kubectl apply” 命 令 重 新 进行 应 用 。 





6.7.3 ”创建 Service 资 源 


Ingress 资 源 仅 通过 Service 资 源 识别 相应 的 Pod 资 源 ， 获 取 其 了 P 和 端 
口 ， 而 后 Ingress 控 制 占 即 可 直接 使 用 各 Pod 对 象 的 IP 地 址 与 它 直 接 进行 
通信 ， 而 不 经 由 Service 资 源 的 代理 和 调度 ， 因 此 Service 资 源 的 ClusterIP 
对 Ingress 控 制 句 来 说 一 无 所 用 。 不 过 ， 大 集群 内 的 其 他 Pod 客 户 端 需要 
与 其 通信 ， 那 么 保留 ClusterIP 似 乎 也 是 很 有 必要 的 。 


下 面 的 配置 文件 中 定义 了 Service 资 源 tomcat-svc， 它 通过 标签 选择 
器 将 相关 的 Pod 对 象 归于 一 组 ， 并 通过 80/TCP 端 口 暴 露 Pod 对 象 的 
8080/TCP 端 口 。 如 果 需 要 暴露 容器 的 8009/TCP 端 口 ， 那 么 只 需要 将 其 
以 类 似 的 格式 配置 于 列表 中 即 可 : 








apiVersion: v1 
kind: Service 
metadata: 
name: tomcat-svc 
namespace: testing 
lJabels: 
app: tomcat-svc 
spec: 
selector: 
app: tomcat 
ports: 
- name: http 
port: 80 
targetPort: 8080 
protocol: TCP 





运行 资源 创建 命令 完成 Service 资 源 的 创建 : 





~]$ kubect1l apply -f tomcat-svc.yaml 





接 看 运行 命令 以 确认 其 成 功 完成 : 





~]$ kubect1l get svc tomcat-svc -n testing 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
tomcat-svc ClusterIP 10.108.72.237 <none> 80/TCP 8s 





6.7.4 创建 Ingress 资 源 


遂 过 Ingress 资 源 的 FQDN 主 机 名 或 URL 路 径 等 类 型 及 布 的 服务 ， 
有 用 户 的 访问 请 求 能 够 匹配 到 其 .spec.rules.host 字 段 定义 的 主机 时 才 和 外 
相应 的 规则 处 理 。 如 果 要 明确 匹配 用 户 的 处 理 请 求 ， 比如 希望 将 那些 发 
往 tomcat.ilinux.io 主 机 的 所 有 请 求 代理 至 tomcat-svc 资 源 的 后 端 Pod， 则 
可 以 使 用 如 下 命令 配置 文件 中 的 内 容 : 








apiVersion: extensions/vibetal 
kind: Ingress 
metadata: 
name: tomcat 
namespace: testing 
annotations: 
kubernetes.io/ingress.class: "nginx" 
spec: 
rules: 
- host: tomcat.ilinux.io 


serviceName: tomcat-svc 
servicePort: 80 





运行 资源 创建 命令 完成 Service 资 源 的 创建 : 





~]$ kubect1l apply -f tomcat-ingress.yaml 





而 后 通过 评 细 信息 确认 其 创建 成 功 完 成 ， 并 且 已 经 正确 关联 到 相应 
的 tomcat-svc 资 源 上 : 





~]$ kubect1 describe ingresses -n testing 


Name : tomcat 
Namespace: testing 
Address: 
Default backend: default-http-backend:80 (<none>) 
Rules: 
Host Path Backends 


tomcat .ilinux.io 

tomcat-svc:80 (<none>) 
Annotations: 

Events: 


了 Reason Age From Message 


Narnia CREATE as nginx-ingress-controller Ingress testing/tomcat 





接 下 来 即 可 通过 Ingress 控 制 器 的 前 端 Service 资 源 的 NodePort 来 访问 
此 服务 ， 在 6.6.4 节 中 ， 此 Service 资 源 的 ClusterIP 被 明确 定义 为 
10.99.99.99， 并 以 节点 端口 30080 映 射 Ingress 控 制 器 的 80 端 口 。 因 此 ， 这 
里 使 用 Ingress 中 定义 的 主机 名 tomcat.ilinux.io: 30080 即 可 访问 tomcat 应 
用 ， 图 6-16 所 示 的 是 访问 页 面 的 效果 。 当 然 ， 实 践 中 ， 其 前 端 应 该 有 一 
个 外 部 的 负载 均衡 设备 接收 并 调度 此 类 请 求 。 





€ 3 CC HO|D tomcatikubemetes,io:30080 呢 | 
Home Documentation Configuration Examples Wiki Mailing Lists Find Help 
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if you're seeing this, you've successfully installed Tomcat. 
Congratulations! 
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图 6-16 ”访问 Ingress 资 源 代理 的 tomcat 应 用 


不 过 ， 用 户 对 tomcat.ilinux.io 主 机 之 外 的 地 址 发 起 的 被 此 Ingress 规 
则 匹配 到 的 请 求 将 了 发 往 Tgress 控 和 j 堪 的 默认 的 后 端 ， 即 default-http- 
backend， 它 通常 只 能 返回 一 个 404 提 示人 信息。 用 户 也 可 按 需 自 定义 默认 
后 端 ， 例 如 ， 如 下 面 的 配置 文件 片断 所 示 ， 它 通过 .spec.backend 定 义 了 
所 有 无 法 由 此 Ingress 匹 配 的 访问 请 求 都 由 相应 的 后 端 default-svc 这 个 
Service 资 源 来 处 理 : 





spec: 
backend: 
serviceName: default-svc 
servicePort: 80 





6.7.5 配置 TLS Ingress 资 源 


一 般 来 说 ， 如 果 有 基于 HITPS 通 信 的 需求 ， 那 么 它 应 该 由 外 部 的 负 
载 均衡 器 (externalL-LB) 予以 实现 ， 并 在 SSL 会 话 御 载 后 将 访问 请 求 转 
发 到 Ingress 控 制 占 。 不 过 ， 如 果 外 部 负载 均衡 器 工作 于 传输 层 而 不 是 工 
作 于 应 用 层 的 反问 代理 服务 上 器， 或 者 存在 直接 通过 Ingress 控 制 器 接收 客 
户 端 请 求 的 需求 ， 义 期 望 它 们 能 够 提供 HTTPS 服 务 时 ， 就 应 该 配置 TLS 
类 型 的 mgress 资 源 。 


将 此 类 服务 公开 发 布 到 互联 网 时 ，HTTPS 服 务 用 到 的 证 书 应 由 公信 
CA 签 晋 并 和 颁发， 用 户 遵循 其 相应 流程 准备 好 相关 的 数字 证 书 即 可 。 如 
果 出 于 测试 或 内 部 使 用 之 目的 ， 那 么 也 可 以 选择 自制 私有 证 书 。openssl 
工具 程序 是 用 于 生成 自 签证 书 的 常用 工具 ， 这 里 使 用 它 生 成 用 于 测试 的 
私 钥 和 目 签 证 书 : 











~]$ openssl genrsa -out tls.key 2048 
~]$ openssl req -new -x509 -key tls,key -out tls.crt \ 
-Subj /C=CN/ST=Beijing/L=Beijing/0=DevOps/CN=tomcat.ilinux.io -days 3650 


© 注意 ”TLS Secret 中 包含 的 证 书 必须 以 tls.crt 作 为 其 键 名 ， 私 
钥 文 件 必须 以 tls.key 为 键 名 ， 因 此 上 面 生 成 的 私 钥 文 件 和 证 书 文 件 名 将 
直接 保存 为 键 名 形式 ， 以 便于 后 面 创建 Secret 对 象 时 直接 作为 键 名 引 
用 。 





在 Ingress 控 制 费 上 配置 HTTPS 主 机 时 ， 不 能 直接 使 用 私 钥 和 证 书 文 
件 ， 而 是 要 使 用 Secret 资 源 对 象 来 传递 相关 的 数据 。 所 以 ， 接 下 来 要 根 
据 私 钥 和 证 书生 成 用 于 配置 TLS Ingress 的 Secret 资 源 ， 在 创建 Ingress 规 
则 时 由 其 将 用 到 的 Secret 资 源 中 的 信息 注入 Ingress 控 制 器 的 Pod 对 象 中 ， 
用 于 为 配置 的 HITPS 虚 拟 主机 提供 相应 的 私 铀 和 证 书 。 下 面 的 命令 会 创 
建 一 个 TLS 类 型 名 为 tomcat-ingress-secret 的 Secret 资 源 : 








~]$ kubectl create secret tls tomcat-ingress-secret --cert=tls.crt --key=tls. 
key -n testing 





可 使 用 下 面 的 命令 确认 Secrets 资 源 tomcat-ingress-secret 创 建成 功 完 





~]$ kubect1 get secrets tomcat-ingress-secret -n testing 
NAME TYPE DATA AGE 
tomcat-ingress-secret kubernetes.io/tls 2 20s 





而 后 去 定义 创建 TLS 类 型 mmgress 资 源 的 配置 清单 。 下 面 的 配置 清单 
通过 spec. rules 定 义 了 一 组 转发 规则 ， 并 通过 .spec.tls 将 此 主机 定义 为 了 
HTTPS 类 型 的 虚拟 主机 ， 用 到 的 私 钥 和 证 书信 息 则 来 自 于 Secrets 资 源 


tomcat-ingress-secret: 





apiVersion: extensions/vibetal 
kind: Ingress 
metadata: 
name: tomcat-ingress-tls 
annotations: 
kubernetes.io/ingress.class: "nginx" 
spec: 
tls: 
- hosts: 
- tomcat.ilinux.io 
secretName: tomcat-ingress-secret 
rules: 
- host: tomcat.ilinux.io 
http: 
paths : 
- path: / 
backend: 
serviceName: tomcat-svc 
servicePort: 80 





运行 资源 创建 命令 完成 Service 资 源 的 创建 : 





~]$ kubect1l apply -f tomcat-ingress-tls.yaml 





而 后 明和 过 详细 信 明确 认 其 创建 成 功 完成 ， 且 已 经 正确 关联 到 相应 的 


tomcat-svc 资 源 : 





~]$ kubectl1 describe ingress tomcat-ingress-tls -n testing 


Name : tomcat -ingress-t1s 
Namespace: testing 
Address: 


Default backend: default-http-backend:80 (<none>) 


TLS: 
tomcat-ingress-secret terminates tomcat.ilinux.io 
Rules: 
Host Path Backends 
tomcat .ilinux.io 
/ tomcat-Svc:80 (<none>) 


Annotations: 
Events: 
Wype Reason A From Message 


No na CREATE 31s nginx-ingress-controller Ingress testing/tomcat-ingress- 
tls 





接 下 来 即 可 通过 Ingress 控 制 器 的 前 ee 务 源 的 NodePort 来 访问 
此 服务 ， 在 6.6.4 节 中 ， 此 Service 资 源 以 节点 端口 30443 映 射 控 制 句 的 443 
端口 。 因 此 ， ie 30443 即 
可 访问 tomcat 应 用 ， 其 访问 到 的 页 面 效 果 类 似 于 图 6-16 中 的 内 容 。 为 
外 ， 也 可 以 使 用 cunl 进 行 访问 测试 ， 只 要 对 应 的 主机 能 够 正确 解析 
tomcat.ilinux.io 主 机 名 即 可 ， 例 如 ， 下 面 的 测试 命令 及 其 输出 表明 ，TLS 
类 型 的 Ingress 已 然 配置 成 功 : 





~]# curl -k -v https://tomcat.ilinux.i0o:30443/ 

* About to connect() to tomcat.ilinux.io port 30443 (#0) 

Trying 172.16.0.66... 

* Server certificate: 

中 subject: CN=tomcat.ilinux.io,0=DevOops,L=Beijing,ST=Beijing,C=CN 
光 start date: Aug 23 07:05:31 2018 GMT 

expire date: Aug 20 07:05:31 2028 GMT 

common name: tomcat.ilinux.io 

issuer: CN=tomcat.ilinux.io,0=DevOps,L=Beijing,ST=Beijing,C=CN 
> GET / HTTP/14.1 

< HTTP/1.1 200 OK 

< Server: nginx/1.13.9 

< Date: Thu, 23 Aug 2018 07:37:40 GMT 








到 此 为 止 ， 实 践 配置 目标 已 经 全 部 达成 。 需 要 再 次 提醒 的 是 ， 在 实 
际 使 用 中 ， 在 集群 之 外 应 该 存在 一 个 用 于 调度 用 户 请 求 至 各 节 点 上 
Ingress 控 制 器 相关 的 NodePort 的 负载 均衡 器 。 如 有 果 不 具有 LBaaS 的 使 用 
条 件 ， 用 户 也 可 以 基于 Nginx、Haproxy、LVS 等 手动 构建 ， 并 通过 
Keepalived 等 解决 方案 实现 其 服务 的 高 可 用 配置 。 





6.8 ”本章 小 结 


本 章 重 点 讲解 了 Kubernetes 的 Service 资 源 及 其 发 布 方式 ， 具 体 如 
下 s 


.Service 资 源 通过 标签 选择 器 为 一 组 Pod 资 源 创建 一 个 统一 的 访问 入 
口 ， 其 可 将 客户 端 请 求 代 理 调 度 至 后 端的 Pod 资 源 。 


'Service 资 源 是 四 层 调度 机 制 ， 默 认 调度 算法 为 随机 调度 。 


.Service 的 实现 模式 有 三 种 : userspace、iptables 和 ipvs。 





.Service 共 用 四 种 类 型 : ClusterIP、NodePort、LoadBalancer 和 
ExternalName， 它 们 用 于 发 布 服 务 。 


.Headless service 是 一 种 特殊 的 Service 资 源 ， 可 用 于 Pod 发 现 。 


-Ingress 资 源 是 发 布 Service 资 源 的 男 一 种 方式 ， 它 需要 结合 Ingress 控 
制 器 才能 正常 工作 。 

.Ingress Controller 的 实现 方式 除了 Nginx 之 外 ， 还 有 Envoy、 
HAProxy、Traefik 等 。 


第 7 草 存储 克 与 数据 持久 化 


应 用 程序 在 处 理 请 求 时 ， 可 根据 其 对 当前 请 求 的 处 理 是 否 受 影响 于 
此 前 的 请 求 ， 将 应 用 划分 为 有 状态 应 用 和 无 状态 应 用 两 种 。 微 服务 体系 
中 ， 各 种 应 用 均 航 拆 分 成 了 众多 微服 务 或 更 小 的 应 用 模块 ， 因 此 往往 会 
存在 为 数 不 少 的 有 状态 应 用 ， 当 然 ， 也 会 存在 数量 可 观 的 无 状态 应 用 。 
而 对 于 有 状态 应 用 来 说 ， 数 据 持久 化 几乎 是 必然 之 需 。 


Kubernetes 提 供 的 存储 卷 (“Volume) 属于 Pod 资 源 级 别 ， 共 享 于 Pod 
内 的 所 有 容器 ， 可 用 于 在 容器 的 文件 系统 之 外 存储 应 用 程序 的 相关 数 
据 ， 甚 至 还 可 独立 于 Pod 的 生命 周期 之 外 实现 数据 持久 化 。 本 章 主要 介 
绍 Kubernetes 系 统 之 上 的 主流 存储 卷 类 型 及 其 应 用 。 




















7.1 存储 卷 概述 


Pod 本 有 身 具有 生命 周期 ， 故 其 内 部 运行 的 容 堪 及 其 相关 数据 自身 均 
无 法 持久 存在 。Docker 支 持 配 置 容器 使 用 存储 卷 将 数据 持久 存储 于 容器 
上 自身 文件 系统 之 外 的 存储 空间 中 ， 它 们 可 以 是 节点 文件 系统 或 网 络 文件 
系统 之 上 的 存储 空间 。 相 应 地 ，Kubernetes 也 支持 类 似 的 存储 卷 功能 ， 
不 过 ， 其 存储 卷 是 与 Pod 资 源 绑 定 而 非 容 堪 。 人 简单 来 说 ， 存 储 卷 是 定义 
在 Pod 资 源 之 上 、 可 被 其 内 部 的 所 有 容器 挂 载 的 共享 目录 ， 它 关联 至 某 
外 部 的 存储 设备 之 上 的 存储 空间 ， 从 而 独立 于 容器 自 呈 的 文件 系统 ， 而 
数据 是 否 具有 持久 能 力 则 取决 于 存储 卷 自 号 是 否 支 持 持久 机 制 。Pod.、 
容器 与 存储 卷 的 关系 如 网 7-1 所 示 。 
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图 7-1 Pod、 容 器 与 存储 卷 





7.1.1 Kubernetes 支 持 的 存储 卷 类 型 


Kubernetes 支 持 非 党 丰富 的 存储 卷 类 型 ， 包 括 本 地 存储 (节点 ) 和 
网 络 存 储 系统 中 的 诸多 存储 机 制 ， 甚 至 还 支持 Secret 和 ConfigMap 这 样 的 
特殊 存储 资源 。 对 于 Pod 来 说 ， 卷 类 型 主要 是 为 关联 相关 的 存储 系统 时 
提供 相关 的 配置 参数 ， 人 例如， 关联 节 点 本 地 的 存储 目录 与 关联 GlusterFS 
存储 系统 所 需要 的 配置 参数 差异 巨大 ， 因 此 指定 存储 卷 类 型 时 也 就 限定 
了 其 关联 到 的 后 端 存储 设备 。 日 前 ，Kubernetes 支 持 的 存储 卷 包 含 以 下 


这 些 类 型 。 











“emptyDir 
‘hostPath 

‘nfs 

fc 

“lscsi 

:flocker 

“Glusterfs 

‘rbd 

‘cephfs 

‘Cinder 
‘awsElasticBlockStore 
‘gcePersistentDisk 
“azureDisk 


“azureFile 


:gitRepo 
‘downwardAPI 
‘ConfigMap 

‘secret 

‘projected 

‘name 
‘persistentVolumeClaim 
‘downwardAPI 
‘vsphereVolume 
‘quobyte 
‘portworxVolume 
‘photonPersistentDisk 
‘scaleIO 

:flexVolume 
‘storageOsS 

“local 


上 述 类 型 中 ，emptyDir 与 hostPath 属 于 节点 级 别 的 卷 类 型 ，emptyDir 
的 生命 周期 与 Pod 资 源 相 同 ， 而 使 用 了 hostPath 卷 的 Pod 一 旦 被 重新 调度 
至 其 他 节点 ， 那 么 它 将 无 法 再 使 用 此 前 的 数据 。 因 此 ， 这 两 种 类 型 都 不 
具有 持久 性 。 要 想 使 用 持久 类 型 的 存储 卷 ， 就 得 使 用 网 络 存 储 系 统 ， 如 
NFS、Ceph、GlusterFS 等 ， 或 者 云端 存储 ， 如 gcePersistentDisk、 


awsElasticBlockStore 等 。 





然而 ， 网 络 存 储 系 统 通 常 都 不 太 容易 使 用 ， 有 的 其 至 很 复杂 ， 以 至 
于 对 大 多 数 用 户 来 说 它 是 一 个 难以 通 越 的 障碍 。Kubernetes 为 此 专门 设 
计 了 一 种 集群 级 别 的 资源 PersistentVolume (简称 PV) ， 它 借 由 管理 员 
配置 存储 系统 ， 而 后 由 用 户 通过 “persistentVolumeClaim” (简称 PVC ) 
存储 卷 直 接 申 请 使 用 的 机 制 大 大 简化 了 终端 存储 用 户 的 配置 过 程 ， 有 效 
降低 了 使 用 难度 。 


再 者 ，Secret 和 ConfigMap 算 得 上 是 两 种 特殊 的 卷 类 型 。 


1) Secret 用 于 同 Pod 传 递 敏感 信息 ， 如 密码 、 私 钥 、 证 书 文件 等 ， 
这 些 信息 如 果 直 接 定 义 在 镜像 中 很 容易 导致 泄露 ， 有 了 Secret 资源 ， 用 
户 可 以 将 这 些 信息 存储 于 集群 中 而 后 由 Pod 进 行 挂 载 ， 从 而 实现 将 敏感 
数据 与 系统 解 耘 。 


2) ConfigMap 资 源 则 用 于 向 Pod 注 入 非 敏感 数据 ， 使 用 时 ， 用 户 将 
数据 直接 存储 于 ConfigMap 对 象 中 ， 而 后 直接 在 Pod 中 使 用 ConfigMap 卷 
引用 它 即 可 ， 它 可 以 帮助 实现 容器 配置 文件 集中 化 定义 和 管理 。 


另外 ，Kubernetes 上 自 1.9 版 本 起 对 存储 的 支持 做 了 进一步 的 增强 ， 引 
入 了 容器 存储 接口 〈Container Storage Interface，CSI) 的 一 套 alpha 实 现 
版 本 ， 其 能 够 将 插件 的 安装 流程 简化 至 与 创建 Pod 相 当 ， 并 允许 第 三 方 
存储 供应 两 在 无 须 修改 Kubernetes 代 码 库 的 前 提 下 提供 自己 的 解决 方 
案 。 因 此 ，Kubermnetes 系 统 文 持 的 卷 存 储 机 制 必 将 进一步 增强 。 











7.1.2 ”存储 卷 的 使 用 方式 


在 Pod 中 定义 使 用 存储 卷 的 配置 由 两 部 分 组 成 : 一 
过 .spec.volumes 字 段 定 义 在 Pod 之 上 的 存储 卷 列 表 ， 其 支持 使 用 多 种 不 
同类 型 的 存储 卷 且 配 置 参 数 差 别 很 大 ;， 男 一 个 是 通 
过 .spec.containers.volumeMounts 字 上 段 在 容器 上 定义 的 存储 卷 挂 载 列表 ， 
它 只 能 挂 载 当 前 Pod 资 源 中 定义 的 具体 存储 卷 ， 当 然 ， 也 可 以 不 挂 载 任 
何 存 储 卷 。 如 图 7-1 所 示 。 


在 Pod 级 别 定义 存储 卷 时 ，.spec.volumes 字 段 的 值 是 对 象 列表 格 
式 ， 每 个 对 象 为 一 个 存储 卷 的 定义 ， 它 由 存储 卷 名 称 
(.spec.volumes.name<String>) 或 存储 卷 对 象 
(.Spec.volumes.VOL_TYPE<Object>) 组 成 ， 其 中 VOL_TYPE 是 使 用 的 
存储 卷 类 型 名 称 ， 它 的 内 花 字 段 随 类 型 的 不 同 而 不 同 。 下 面 的 资源 清单 
片段 定义 了 由 两 个 存储 卷 组 成 的 卷 列 表 ， 一 个 是 emptyDir 类 型 ， 一 个 是 
gitRepo 类 型 : 











spec: 


volumes: 
- Name: logdata 
emptyDir: {} 
- name: example 
gitRepo: 

repository: https://github.com/ikubernetes/k8s_book.git 
revision: master 
directory: ， 


定义 好 的 存储 卷 可 由 当 前 Pod 资 源 内 的 各 容 涡 进行 挂 载 。 事实 上 ， 

只 有 多 个 容器 挂 载 同 一 个 存储 卷 时 , “共享 ” 才 有 了 具体 的 意义 。 当 
有 一 个 容器 时 ， 使 用 存储 卷 的 目的 通常 在 于 数据 持久 
化 。.spec.containers.volumeMounts 字 有 段 的 值 也 是 对 象 列表 格式 ， 由 一 到 
多 个 存储 卷 挂 载 定 义 组 成 。 无 论 何 种 类 型 的 存储 郑 ， 它 们 的 挂 载 格 式 基 
本 上 都 是 相同 的 ， 下 面 的 代码 段 是 在 容器 中 定义 挂 载 卷 时 的 通用 语法 形 


武 ， 




















spec: 


containers: 


- name: <String> 


volumeMounts: 

- name <string> -required- 
mountPath <string> -required- 
readonly <boolean> 
SubPath <string> 
mountPropagation <string> 





其 中 各 字段 的 意义 及 使 用 要 求 具体 如 下 。 
-name<string>: 指定 要 挂 载 的 存储 的 名 称 ， 必 选 字段 。 
.mountPath<string>: 挂 载 点 路 径 ， 容 髓 文件 系统 上 的 路 径 ， 必 选 字 


:readOnly<boolean>: 是 否 挂 载 为 只 读 卷 。 


subPath<string>: 挂 载 存 储 卷 时 使 用 的 子路 径 ， 即 在 mountPath 指 
定 的 路 径 下 使 用 一 个 子路 径 作 为 其 挂 载 点 。 


下 面 是 一 个 挂 载 示例 ， 容 器 myapp 将 logdata 存 储 卷 挂 载 
于 /vavlog/myapp， 将 example 挂 载 到 /webdata/example 目 录 : 





spec: 
containers: 
- name: myapp 
image: ikubernetes/myapp:v7 
volumeMounts: 
- name: logdata 
mountPath: /var/log/myapp/ 
- name: example 
mountPath: /webdata/example/ 





存储 卷 的 定义 基本 相似 ， 因 此 本 章 后 面 的 篇 幅 将 重点 放 在 介绍 主流 
存储 卷 类 型 的 配置 及 使 用 方式 ， 而 且 出 于 保持 示例 简洁 及 市 约 篇 幅 的 目 
的 ， 本 章 的 示例 主要 以 自主 式 Pod 资 源 为 主 。 





7.2 ”临时 存储 卷 


Kubernetes 支 持 存 储 卷 类 型 中 ，emptyDir 存 储 卷 的 生命 周期 与 其 所 
属 的 Pod 对 象 相同 ， 它 无 法 脱离 Pod 对 象 的 生命 周期 提供 数据 存储 功能 ， 
因此 emptyDir 通 常 仅 用 于 数据 缓存 或 临时 存储 。 不 过 ， 基 于 emptyDir 构 
建 的 gitRepo 存 储 卷 可 以 在 Pod 对 象 的 生命 周期 起 始 时 从 相应 的 Git 仓 库 中 
0 “0 的 emptyDir 中 ， 从 而 使 得 它 具 有 了 一 定 意义 
持久 性 。 








7.2.1 emptyDir 存 储 卷 





emptyDir 存 储 卷 是 Pod 对 象 生 命 周 期 中 的 一 个 临时 目录 ， 类 似 于 
Docker 上 的 “docker 挂 载 卷 ”， 在 Pod 对 象 司 动 时 即 被 创建 ， 而 在 Pod 对 象 
被 移 除 时 会 被 一 并 删除 。 不 具有 持久 能 力 的 emptyDir 存 储 卷 只 能 用 于 某 
些 特 殊 场 景 中 ， 例 如 ， 同 一 Pod 内 的 多 个 容器 则 文件 的 共享 ， 或 者 作为 
容 右 数据 的 临时 存储 目录 用 于 数据 绥 存 系统 等 。 


emptyDir 存 储 卷 则 定义 于 .spec.volumes.emptyDir 杉 套 字 段 中 ， 可 用 
字段 主要 包含 两 个 ， 具 体 如 下 。 


:medium: 此 目录 所 在 的 存储 介质 的 类 型 ， 可 取 值 
为 “default”* 或 “Memory”， 默 认为 default， 表 示 使 用 节点 的 默认 存储 介 
质 ; “Memory” 表 示 使 用 基于 RAM 的 临时 文件 系统 trmpfs， 空 间 受 限于 内 
存 ， 但 性 能 非常 好 ， 通 常用 于 为 容器 中 的 应 用 提供 缓存 空间 。 


“sizeLimit: 当前 存储 卷 的 空间 限额 ， 上 默认 值 为 i， 表示 不 限制 ， 不 
过 ， 在 medium 字 段 值 为 “Memory” 时 建议 务必 定义 此 限额 。 


下 面 是 一 个 使 用 了 emptyDir 存 储 卷 的 简单 示例 ， 它 保存 于 vol- 
emptydir.yaml 配 置 文 件 中 : 

















apiVersion: v1 
kind: Pod 
metadata: 
name: vol-emptydir-pod 
spec: 
volumes: 
- name: html 
emptyDir: {} 
containers: 
- name: nginx 
image: nginx:1.12-alpine 
volumeMounts: 
- name: html 
mountPath: /usr/share/nginx/html 
- name: pagegen 
image: alpine 
volumeMounts: 
- name: html 
mountPath: /html 
command: ["/bin/sh", "-c"] 
args: 
- while true; do 


echo $(hostname) $(date) >> /html/index.html; 
sleep 10; 
done 





上 面 的 示例 中 定义 的 存储 卷 名 称 为 html， 挂 载 于 容器 nginx 
的 /usr/share/nginx/html 目 录 ， 以 及 容器 pagegen 的 /html 目 录 。 容 器 
pagegen 每 隔 10 秒 向 存储 卷 上 的 index.html 文 件 中 追加 一 行 信 息 ， 而 容器 
nginx 中 的 nginx 进 程 则 以 其 为 站 点 主页 ， 如 图 7-2 所 示 。 


Pr" 


Container:pagegen 
/html 





图 7-2 ”存储 卷 使 用 示意 图 


Pod 资 源 的 详细 信息 中 会 显示 存储 卷 的 相关 状态 ， 包 括 其 是 否 创建 
成 功 〈 在 Events 字 段 中 输出 ) 、 相 关 的 类 型 及 参数 (在 Volumes 字 上 段 中 
输出 ) 以 及 容器 中 的 挂 载 状态 等 信息 〈 在 Containers 字 段 中 输出 ) 。 如 
下 面 的 命令 结果 所 示 ; 








~]$ kubect1 describe pods vol-emptydir-pod 
Name : vol-emptydir-pod 
nginx: 


/usr/share/nginx/html from html (rw) 
pagegen: 
Mounts: 
/html from html (rw) 


Volumes: 


html: 
Type: EmptyDir (a temporary directory that shares a pod's lifetime) 
Medium: 
Events 
ype Reason A From Message 


No ma Scheduled 10s es scheduler Successfully assigned vol-emptydir 
to node03.ilinux.io 

Normal SuccessfulMountVolume 10s kubelet, node03.ilinux.io MountVolume. 
SetUp succeeded for volume "html" 





而 后 ， Oe te ad 或 者 在 集群 中 直 
， 问 请 求 ， 以 测试 两 个 容器 通过 emptyDir 卷 共享 数 
据 的 结果 状态 





~]$ curl 10.1.3.106 
vol-emptydir Wed Mar 7 01:10:56 UTC 2018 





作为 边 车 (sidecar) 的 容器 paggen， 其 每 隔 10 秒 生成 一 行 信息 追加 
到 存储 卷 上 的 index.html 文 件 中 ， 因 此 ， 通 交 过 主 容 右 nginx 的 应 用 访问 到 
的 内 容 也 会 处 于 不 停 的 变动 中 。 另 外 ，emptyDir 存 储 卷 也 可 以 基于 RAM 
创建 tmnpfs 文 件 系 统 的 存储 卷 ， 弟 用 于 为 容器 的 应 用 提供 高 性 能 缓存 ， 
下 面 是 一 个 配置 示例 : 











volumes: 
- Name: cache 
emptyDir: 
medium: Memory 





emptyDir 卷 简单 易 用 ， 但 仅 能 用 于 临时 存储 。 另 外 还 存在 一 些 类 型 
的 存储 卷 建构 在 emptyDir 之 上 ， 并 额外 提供 了 它 所 没有 的 功能 ， 例 如 ， 
将 于 7.2.2 节 介绍 的 gitRepo 存 储 卷 。 


7.2.2 ”gitRepo 存 储 卷 


gitRepo 存 储 卷 可 以 看 作 是 emptyDir 存 储 卷 的 一 种 实际 应 用 ， 使 用 该 
存储 卷 的 Pod 资 源 可 以 通过 挂 载 目录 访问 指定 的 代码 仓库 中 的 数据 。 使 
用 gitRepo 存 储 卷 的 Pod 资 源 在 创建 时 ， 会 首先 创建 一 个 空 目 录 

CemptyDir) 并 元 隆 (clone) 一 份 指 定 的 Git 仓 库 中 的 数据 至 该 目录 ， 
而 后 再 创建 容器 并 挂 载 该 存储 卷 。 


定义 gitRepo 类 型 的 存储 卷 时 ， 其 可 授 套 使 用 的 字段 具体 包含 如 下 三 





:repository<string> : Git 仓 库 的 URL， 必 选 字 有 段 。 

-directory<string> : 目标 目录 名 称 ， 名 称 中 不 能 包含 “..” 字 符 ;“.” 表 
示 将 仓库 中 的 数据 直接 复制 到 卷 目 录 中 ， 人 否则 ， 即 为 复制 到 卷 目 录 中 以 
用 户 指定 的 字符 串 为 名 称 的 子 目 录 中 。 


:revision<string> : 特定 revision 的 提交 哈 希 码 。 





O 注意 ”使 用 gitRepo 存 储 卷 的 Pod 资 源 运 行 的 工作 节点 上 必须 
安装 有 Git 程 序 ， 否 则 元 隆 仓 库 的 操作 将 无 从 完成 。 男 外 ， 自 Kubernetes 
1.12 起 ，gitRepo 存 储 卷 已 经 被 废弃 。 


下 面 示例 (vol-gitrepo.yaml 配 置 文件 ) 中 的 Pod 资 源 在 创建 时 ， 首 
先 会 创建 一 个 空 目 录 ， 将 指定 的 Git 仓 库 
https://github.com/iKubernetes/k8s_book.git 中 的 数据 复制 一 份 直接 保存 于 
此 目录 中 ， 而 后 将 此 目录 创建 为 存储 卷 html， 最 后 由 容器 Nginx 将 此 存 
储 卷 挂 载 于 /usr/share/nginx/html 目 录 上 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: vol-gitrepo-pod 
spec: 
containers: 
- name: nginx 
image: nginx:1.12-alpine 
volumeMounts: 


- name: html 
mountPath: /usr/share/nginx/html 
VOLumes : 
- name: html 
gitRepo: 
repository: https://github.com/ikubernetes/k8s_book.git 
directory: . 
revision: "master" 


访问 此 Pod 资 源 中 的 Nginx 服 务 即 可 看 到 其 来 自 于 Git 仓 库 中 的 页 面 
资源 。 不 过 ，gitRepo 存 储 卷 在 其 创建 完成 后 不 会 再 与 指定 的 仓库 执行 同 
步 操 作 ， 这 就 意味 着 在 Pod 资 源 运行 期 间 ， 如 果 仓 库 中 的 数据 发 生 了 变 
化 ， 那 么 gitRepo 存 储 卷 不 会 同步 到 这 些 内 容 。 当 然 ， 此 时 可 以 为 Pod 资 
源 创建 一 个 专用 的 边 车 容器 用 于 执行 此 类 的 同步 操作 ， 尤 其 是 数据 来 源 
于 私有 仓库 时 ， 通 过 边 车 容器 完成 其 复制 就 更 为 必要 。 


gitRepo 存 储 卷 建构 于 emptyDir 存 储 卷 之 上 ， 它 的 生命 周期 与 隶属 的 
Pod 对 象 相 同 ， 因 此 使 用 时 不 建议 在 此 类 存储 卷 中 保存 由 容器 生成 的 重 
要 数据 。 另 外 ， 目 Kubernetes 1.12 版 起 ，gitRepo 存 储 卷 已 经 被 废弃 ， 所 
以 在 之 后 的 版 本 中 和 硅 要 使 用 它 配 置 Pod 对 象 ， 建 议 读者 借助 初始 化 容器 

CInitContainer) 将 仓库 中 的 数据 复制 到 emptyDir 存 储 卷 上 ， 并 在 主 容器 
中 使 用 此 存储 卷 。 














7.3 ”市 扩 存 储存 hostPath 


hostPath 类 型 的 存储 卷 是 指 将 工作 节点 上 某 文件 系统 的 目录 或 文件 
挂 载 于 Pod 中 的 一 种 存储 卷 ， 它 可 独立 于 Pod 资 源 的 生命 周期 ， 因 而 具有 
持久 性 。 但 它 是 工作 节点 本 地 的 存储 空间 ， 仪 适用 于 特定 情况 下 的 存储 
卷 使 用 需求 ， 例 如 ， 将 工作 厄 点 上 的 文件 系统 关联 为 Pod 的 存储 卷 ， 从 
而 使 得 容器 访问 市 点 文件 系统 上 的 数据 。 这 一 点 在 运行 有 管理 任务 的 系 
统 级 Pod 资 源 需 要 访问 节点 上 的 文件 时 尤为 有 用 。 

配置 hostPath 存 储 卷 的 蝶 套 字段 共有 两 个 : 一 个 是 用 于 指定 工作 区 
护 上 的 目录 路 人 径 的 必 选 字段 path; 男 一 个 是 指定 存储 卷 类 型 的 type， 它 
支持 使 用 的 卷 类 型 包含 如 下 几 种 。 


DirectoryOrCreate: 指定 的 路 径 不 存 时 自动 将 其 创建 为 权限 是 0755 
的 空 目 录 ， 属 主 属 组 均 为 kubelet。 


Directory: 必须 存在 的 目录 路 径 。 


:FileOrCreate: 指定 的 路 径 不 存 时 自动 将 其 创建 为 权限 是 0644 的 空 
文件 ， 属 主 和 属 组 同 是 kubelet。 


:File: 必须 存在 的 文件 路 径 。 


.Socket: 必须 存在 的 Socket 文 件 路 径 。 
































“CharDevice: 必须 存在 的 字符 设备 文件 路 径 。 
.BlockDevice: 必须 存在 的 块 设备 文件 路 径 。 
下 面 是 定义 在 vol-hostpath.yaml 配 置 文件 中 的 Pod 资 源 ， 它 运行 着 日 


志 收 集 代 理应 用 filebeat， 负 责 收集 工作 节点 及 容器 相关 的 日 志 信 息 发 往 
Redis 服 务 器 ， 它 使 用 了 三 个 hostPath 类 型 的 存储 卷 : 








apiVersion: v1 
kind: Pod 
metadata: 
name: vol-hostpath-pod 
spec: 
containers: 


- name: filebeat 
image: ikubernetes/filebeat:5.6.7-alpine 
env: 
- name: REDIS_ HOST 
value: redis.ilinux.io:6379 
- Name: LOG LEVEL 
value: info 
volumeMounts: 
- name: varlog 
mountPath: /var/log 
- name: socket 
mountPath: /var/run/docker.sock 
- name: varlibdockercontainers 
mountPath: /var/lib/docker/containers 
readonly: true 
terminationGracePeriodSeconds: 30 
vOolumes: 
- name: varlog 
hostPath : 
path: /var/log 
- name: varlibdockercontainers 
hostPath : 
path: /var/lib/docker/containers 
- name: socket 
hostPath : 
path: /var/run/docker.sock 





这 类 Pod 资 源 通常 受 控 于 daemonset 类 型 的 Pod 控 制 器 ， 它 运行 于 集 
群 中 的 每 个 工作 节点 之 上 ， 负 责 收 集 工作 节点 上 系统 级 的 相关 数据 ， 
此 使 用 hostPath 存 储 卷 也 是 理 所 应 当 的 。 读 者 在 创建 上 述 Pod 资 源 时 ， 如 
果 有 可 用 的 Redis 服 务 器 ， 则 可 通过 环境 变量 REDIS_HOST 传 递 给 Pod 资 
源 ， 待 其 Ready 之 后 即 可 通过 Redis 服 务 嚣 查看 到 由 其 友 送 的 日 志 信 息 。 
在 filebeat 的 应 用 架构 中 ， 这 些 日 志 信 息 会 发 往 Elasticsearch， 并 通过 
Kibana 进 行 展 示 。 


另外 ， 使 用 hostPath 存 储 卷 时 需要 注意 到 ， 不 同 节点 上 的 文件 或 许 
并 不 完全 相同 ， 于 是 ， 那 些 要 求 事先 必须 存在 的 文件 或 目录 的 满足 状态 
也 可 能 会 有 所 不 同 ， 另 外 ， 基 于 资源 可 用 状态 的 调度 器 调度 Pod 时 ， 
hostpath 资 源 的 可 用 性 状态 不 会 被 考虑 在 内 ， 再 者 ， 在 节点 中 创建 的 文 
件 或 目录 默认 仅 有 root 可 写 ， 若 期 望 容器 内 的 进程 拥有 写 权限 ， 则 要 么 
将 它 运行 为 特权 容器 ， 要 么 修改 节点 上 目录 路 径 的 权限 。 


那些 并 非 执 行 系统 级 管理 任务 的 且 不 受 控 于 Daemonset 控 制 右 的 无 
状态 应 用 在 Pod 资 源 被 重新 调度 至 其 他 节点 运行 时 ， 此 前 创建 的 文件 或 
目录 大 多 都 不 会 存在 。 因 此 ，hostPath 存 储 卷 虽然 能 持久 保存 数据 ， 但 
对 于 被 调度 器 按 需 调度 的 应 用 来 说 并 不 适用 ， 这 时 需要 用 到 的 是 独立 于 
集群 节点 的 持久 性 存储 卷 ， 即 网 络 存储 卷 。 




















7.4 网 络 存储 卷 


如 前 所 述 ，Kubernetes 拥 有 众多 类 型 的 用 于 适 配 专用 存储 系统 的 网 
络 存储 卷 。 这 类 存储 卷 包括 传统 的 NAS 或 SAN 设 备 〈 如 NEFS、iSCSI、 
fc) 、 分 布 式 存储 〈 如 GlusterFS、RBD) 、 云 端 存储 《〈 如 
gcePersistentDisk、azureDisk、cinder 和 awsElasticBlockStore) 以 及 建构 
在 各 类 存储 系统 之 上 的 抽象 管理 层 ( 如 flocker、portworxVolume 和 


VvsphereVolume ) 等 。 








7.4.1 NEFS 存 储 卷 


NFS 即 网 络 文件 系统 (Network File System ) ， 它 是 一 种 分 布 式 文 
件 系 统 协议 ， 最 初 是 由 Sun MicroSystems 公 司 开 发 的 类 Unix 操 作 系 统 之 
上 的 一 于 经 典 的 网 络 存储 方案 ， 其 功能 则 在 允许 客户 端 主机 可 以 像 访问 
本 地 存储 一 样 通过 网 络 访问 服务 器 端 文件 。 作 为 一 种 由 内 核 原 生 文 持 的 
2 具有 Linux 系 统 使 用 经 验 的 读者 大 多 数 都 应 该 对 NFS 有 
一 起 全 人 


Kubernetes 的 NFS 存 储 卷 用 于 将 某 事先 存在 的 NFS 服 务 占 上 导出 
Cexport) 的 存储 空间 挂 载 到 Pod 中 以 供 容 器 使 用 。 与 emptyDir 不 同 的 
是 ，NFS 存 储 卷 在 Pod 对 象 终止 后 仪 是 被 凶 载 而 非 删除 。 男 外 ，NFS 是 
文件 系统 级 共享 服务 ， 它 支持 同时 存在 的 多 路 挂 载 请 求 。 定 义 NFS 存 储 
卷 时 ， 常 用 到 以 下 字段 。 


server<string> : NFS 服 务 器 的 IP 地 址 或 主机 名 ， 必 选 字 段 。 


:path<string> : NFS 服 务 器 导出 《共享 ) 的 文件 系统 路 径 ， 必 选 字 











层 ， 


TeadOnly<boolean>: 是 否 以 只 读 方 式 挂 载 ， 默 认为 false。 


Redis (REmote DIctionary Server) 是 一 个 著名 的 高 性 能 key-value 存 
储 系统 ， 应 用 非 剃 广泛， 将 其 部 普 运 行 于 Kubernetes 系 统 之 上 时 ， 需 要 
持久 化 存储 卷 的 支持 。 下 面 是 简单 使 用 Redis 的 一 个 示例 : 





apiVersion: v1 
kind: Pod 
metadata: 
name: vol-nfs-pod 
lJabels: 
app: redis 
spec: 
containers: 
- name: redis 
image: redis:4-alpine 
ports: 
- containerPort: 6379 
name: redisport 
volumeMounts: 
- mountPath: /data 
name: redisdata 


VOLumes : 
- name: redisdata 
nfs: 
server: nfs.ilinux.io 
path: /data/redis 
readonly: false 





上 面 的 示例 定义 在 资源 配置 文件 vol-nfs.yaml 中 ， 其 中 的 Pod 资 源 拥 
有 一 个 关联 至 NFS 服 务 器 nfs.ilinux.io 的 存储 卷 ，Redis 容 器 将 其 挂 载 
于 /data 目 录 上 ， 它 是 运行 于 容器 中 的 redis-server 数 据 的 持久 保存 位 置 。 





名 提示 。 这 里 应 确保 事先 要 存在 一 个 名 为 nfs.ilinux.io 的 NFS 服 
务 器 ， 其 输出 了 /data/redis 目 录 ， 并 授权 给 了 Kubemetes 集 群 中 的 节点 访 
问 。 主 机 和 目录 都 可 以 按 需要 进行 调整 。 


资源 创建 完成 后 ， 可 通过 其 命令 客户 端 redis-cli 创 建 测试 数据 ， 并 
手动 触发 其 同步 于 存储 系统 中 ， 下 面 加 粗 部 分 的 字体 为 要 执行 的 Redis 


从 人 人 
命令 : 





~]$ kubect1 exec -it vol-nfs-pod redis-cli 
127.0.0.1:6379> set mykey "hello ilinux.io" 
OK 

127.0.0.1:6379> get mykey 

"hello ilinux.io" 

127.0.0.1:6379> BGSAVE 

Background saving started 

127.0.0.1:6379> exit 





为 了 测试 其 数据 持久 化 效果 ， 下 面 删除 Pod 资 源 vol-nfs-pod， 并 于 
再 次 重建 后 检测 数据 是 否 依然 能 够 访问 : 





~]$ kubect1l delete pods vol-nfs-pod 
pod "vol-nfs-pod" deleted 

~]$ kubect1l apply -f vol-nfs.yaml 
pod "vol-nfs-pod" created 





竺 其 重建 完成 后 ， 通 过 再 一 次 创建 的 Pod 资 源 的 详细 信息 ， 我 们 可 
以 观察 到 它 挂 载 使 用 NFS 存 储 卷 的 相关 信息 。 接 下 来 再 次 检查 redis- 
server 中 是 否 还 保存 有 此 前 存储 的 数据 : 











~]$ kubect1 exec -it vol-nfs-pod redis-cli 
127.0.0.1:6379> get mykey 

"hello ilinux.io" 

127.0.0.1:6379> 





从 上 面 的 命令 结果 中 可 以 看 出 ， 此 前 创建 的 键 mykey 及 其 数据 在 
Pod 资 源 重建 后 依然 存在 ， 这 表明 在 删除 Pod 资 源 时 ， 其 关联 的 外 部 存储 
卷 并 不 会 被 一 同 删除 。 如 果 需 要 清除 此 类 的 数据 ， 需 要 用 户 通 过 存储 系 
统 的 管理 接口 手动 进行 。 





7.4.2 RBD 存 储 卷 





Ceph 是 一 个 专注 于 分 布 式 的 、 弹 性 可 扩展 的 、 高 可 靠 的 、 性 能 优 措 
的 存储 系统 平台 ， 同 时 文 持 提供 块 设备 、 文 件 系统 和 REST 三 种 存储 接 
口 。 它 是 一 个 高 度 可 配置 的 系统 ， 并 提供 了 一 个 命令 行 界 面 用 于 监视 和 
控制 其 存储 集群 。Ceph 还 包含 鉴证 和 授权 功能 ， 可 兼容 多 种 存储 网 关 接 
口 ， 如 OpenStack Swift 和 Amazon S3。Kubernetes 也 支持 通过 RBD 卷 类 型 
使 用 Ceph 存 储 系 统 为 Pod 提 供 存储 卷 。 要 配置 Pod 资 源 使 用 RBD 存 储 
卷 ， 需 要 事先 满足 如 下 几 个 前 提 条 件 。 


存在 茶 可 用 的 Ceph RBD 存 储 集群 ， 否 则 惑 需 要 创建 一 个 。 


在 Ceph RBD 集 群 中 创建 一 个 能 满足 Pod 资 源 数据 存储 需要 的 存储 
映像 (image) 。 


` 在 Kubernetes 集 群 内 的 各 节点 上 安装 Ceph 客 户 端 程序 包 (ceph- 


common) 。 


在 配置 RBD 类 型 的 存储 卷 时 ， 需 要 指定 要 连接 的 目标 服务 器 和 认证 
信息 等 ， 这 一 点 通常 使 用 以 下 骨 套 字段 进行 定义 。 


-monitors<[]string>: Ceph 存 储 监 视 器 ， 喜 号 分 隅 的 字符 串 列 表 ; 必 
选 字段 。 


"image<string>: rados image 的 名 称 ， 必 选 字段 。 

















.Dool<string>: rados 存 储 池 名 称 ， 默 认为 RBD。 
'User<string>: Iados 用 户 名 ， 默 认为 admin。 


.keyring<string>: RBD 用 户 认 证 时 使 用 的 keyring 文 件 路 径 ， 默 认 
为 /etc/ceph/keyring。 


secretRef<Object>: RBD 用 户 认 证 时 使 用 的 保存 有 相应 认证 信息 的 
Secret 对 象 ， 会 覆盖 由 keyring 字 段 提 供 的 密 钥 信息 。 


:readOnly<string>: 是 否 以 只 读 的 方式 进行 访问 。 


:fsType: 要 挂 载 的 存储 卷 的 文件 系统 类 型 ， 至 少 应 该 是 节点 操作 系 
统 支持 的 文件 系统 ， 如 ext4、xfs、ntfs 等 ， 默 认为 ext4。 


下 面 是 一 个 定义 在 vol-rbd.yaml 配 置 文件 中 使 用 RBD 存 储 卷 的 Pod 资 
源 示例 : 





apiVersion: v1 
kind: Pod 
metadata: 
name: vol-rbd-pod 
spec: 
containers: 
- name: redis 
image: redis:4-alpine 
ports: 
- containerPort: 6379 
name: redisport 
volumeMounts: 
- mountPath: /data 
name: redis-rbd-vol 
volumes: 
- name: redis-rbd-vol 
rbd: 
monitors: 
- '172.16.0.56:6789' 
- '172.16.0.57:6789' 
- '172.16.0.58:6789' 
pool: kube 
image: redis 
fsType: ext4 
readonly: false 
user: admin 
SecretRef : 
name: ceph-secret 





此 示例 依赖 于 事先 存在 的 一 个 Ceph 存 储 集群 ， 这 里 假设 其 监视 器 的 
地 址 为 172.16.0.56、172.16.0.57 和 172.16.0.58 三 个 主机 了 PP， 并 且 集 群 上 的 
存储 池 kube 中 存在 创建 好 的 映像 Redis， 此 映像 拥有 ext4 文 件 系 统 。Ceph 
客户 端 访 问 集群 时 需要 事先 完成 认证 之 后 才能 进行 后 续 的 访问 操作 ， 此 
示例 上 ， 其 认证 信息 保存 于 名 为 ceph-secret 的 Secret 资 源 对 象 中 。 示 例 所 
实现 的 逻辑 架构 如 图 7-3 所 示 。 








图 7-3 ”RBD 存 储 卷 


@ 此 配置 示例 依赖 于 一 个 可 用 的 Ceph 集 群 ， 且 上 述 配置 
示例 中 的 部 分 参数 需要 参照 实际 环境 进行 修改 。 


7.4.3 ”GlusterFS 存 储 卷 


GlusterFS (Gluster File System ) 是 一 个 开源 的 分 布 式 文件 系统 ， 是 
水 平 扩 展 存 储 解决 方案 Gluster 的 核心 ， 具 有 强大 的 横 癌 扩展 能 力 ， 
GlusterFS 通 过 扩展 能 够 支持 数 PB 存 储 容 量 和 处 理 数 千 客 户 端 。 
GlusterFS 借 助 TCP/IP 或 InfiniBand RDMA 网 络 将 物理 分 布 的 存储 资源 聚 
集 在 一 起 ， 使 用 单一 全 局 命名 空间 来 管理 数据 。 另 外 ，GlusterFS 基 于 可 
堆 县 的 用 户 空 间 设计 ， 可 为 各 种 不 同 的 数据 负载 提供 优异 的 性 能 ， 是 另 
一 种 流行 的 分 布 式 存储 解决 方案 。 要 配置 Pod 资 源 使 用 GlusterFS 存 储 
卷 ， 需 要 事先 满足 以 下 前 提 条 件 。 


1) 存在 茶 可 用 的 GlusterFS 存 储 集群 ， 售 则 就 要 创建 一 个 。 
2) 在 GlusterFS 集 群 中 创建 一 个 能 满足 Pod 资 源 数据 存储 需要 的 卷 。 


3) 在 Kubernetes 集 群 内 的 各 节点 上 安装 GlusterFS 客 户 端 程序 包 
(glusterfs 和 glusterfs-fuse ) 。 


另外 ， 若 要 基于 GlusterFS 使 用 存储 卷 的 动态 供给 机 制 〈 请 参考 7.5.6 
节 ) ， 还 需要 事先 部 署 heketi， 它 用 于 为 GlusterFS 集 群 提供 RESTful 风 格 
的 管理 接口 。Gluster 存 储 集 群 及 heketi 的 配置 示例 请 参考 附录 了 B。 


定义 Pod 资 源 使 用 GlusterFS 类 型 的 存储 卷 时 ， 常 用 的 配置 字段 包含 
gr hes 


endpoints<string>: Endpoints 资 源 的 名 称 ， 此 资源 需要 事先 存在 ， 
用 于 提供 Gluster 集 群 的 部 分 节点 信息 作为 其 访问 入 口 ;， 必 选 字段 。 


:path<string>: 用 到 的 GlusterFS 集 群 的 卷 路 径 ， 如 kube-redis;， 必 选 
字段 。 























:readOnly<boolean>: 是 否 为 只 读 卷 。 


下 面 是 一 个 定义 在 vol-glusterfs.yaml 配 置 文件 中 的 Pod 资 源 示例 ， 它 
使 用 了 GlusterFS 存 储 卷 持久 保存 应 用 数据 。 它 通过 glusterfs-endpoints 资 
源 中 定义 的 GlusterFS 集 群 节点 信息 接 入 集群 ， 并 以 kube-redis 卷 作为 Pod 


资源 的 存储 卷 。glusterfs-endpoints 资 源 需要 在 Kubernetes 集 群 中 事先 创 
建 ， 而 kube-redis 则 需要 事先 创建 于 Gluster 集 群 : 





apiVersion: v1 
kind: Pod 
metadata: 
name: vol-glusterfs-pod 
labels: 
app: redis 
spec: 
containers: 
- name: redis 
image: redis:alpine 
ports: 
- containerPort: 6379 
name: redisport 
volumeMounts: 
- mountPath: /data 
name: redisdata 
volumes: 
- name: redisdata 
glusterfs: 
endpoints: glusterfs-endpoints 
path: kube-redis 
readonly: false 








用 于 访问 Gluster 集 群 的 相关 节点 信息 要 事先 保存 于 某 特定 的 
Endpoints 资 源 中 ， 例 如 上 面 示例 中 调 用 的 glusterfs-endpoints。 此 类 的 
Endpoints 资 源 可 由 用 户 根 据 实际 需求 手动 创建 例如， 下面 的 保存 于 
glusterfs-endpoints. yu 中 的 资源 示例 中 定义 了 三 个 接 入 相关 的 
Gluster 存 储 集群 的 节点 gfs01.ilinux.io、gfs02.ilinux.io 和 gfs03.ilinux.io， 


Ur 中 信息 仅 为 注 是 Endpoints 资 9 源 的 必 选 字段 要 求 ， 因 此 其 值 可 以 
随意 意 填 











apiVersion: v1 
kind: Endpoints 
metadata: 
name: glusterfs-endpoints 
subsets: 
- addresses : 
- ip: gfs01.ilinux.io 
ports: 
- port: 24007 
name: glusterd 
- addresses : 
- ip: gfs02.ilinux.io 
ports: 
- port: 24007 
name: glusterd 
- addresses : 
- ip: gfs03.ilinux.io 


ports: 
- port: 24007 
name: glusterd 





首先 创建 Endpoints 资 源 glusterfs-endpoints， 而 后 再 创建 Pod 资 源 vol- 
glusterfs-pod， 即 可 测试 其 数据 持久 存储 的 效果 。 


7.4.4 Cinder 存 储 卷 


Cinder 是 OpenStack Block Storage 的 项 目 名 称 ， 用 来 为 虚拟 机 
(VM) 实例 提供 持久 块 存 储 。Cinder 通 过 驱动 架构 支持 多 种 后 端 
(back-end) 存储 方式 ， 包 括 LVM、NFS、Ceph 和 其 他 诸如 EMC、IBM 
等 商业 存储 产品 和 方案 ， 其 提供 了 调用 度 来 调度 卷 创建 的 请 求 ， 能 合理 
优化 存储 资源 的 分 配 ， 而 且 还 拥有 REST API。 将 Kubernetes 和 集群 部 署 于 
OpenStack 构 建 的 IaaS 环 境 中 时 ，Cinder 的 块 存 储 功 能 可 为 Pod 资 源 提供 
外 部 持久 存储 的 有 效 方式 。 


在 Pod 资 源 上 定义 使 用 Cinder 存 储 卷 时 ， 其 可 用 的 藤 套 字段 包含 如 
下 


volumeID<string>: 用 于 标识 Cinder 中 的 存储 卷 的 卷 标识 符 ， 必 选 
字段 。 








TeadOnly<boolean>: 是 否 以 只 读 方式 访问 。 


fsType: 要 挂 载 的 存储 卷 的 文件 系统 类 型 ， 至 少 应 该 是 节点 操作 系 
统 支持 的 文件 系统 ， 如 ext4、xfs、ntfs 等 ， 默 认为 “ext4”。 


下 面 的 资源 清单 是 定义 在 vol-cinder.yaml 文 件 中 的 使 用 示例 ， 假 设 
在 OpenStack 环 境 中 有 创建 好 的 Cinder 卷 “e2b8d2f7-wece-90d1-a505- 
4acf607a90bc” 可 用 : 





apiVersion: v1 
kind: Pod 
metadata: 
name: vol-cinder-pod 
spec: 
containers: 
- image: mysql 
name: mysql 
args: 
- "--ignore-db-dir" 
- "lost+found" 
env: 
- Name: MYSQL_ROOT_PASSWORD 
value: YOUR_PASS 
ports: 
- containerPort: 3306 
name: mysqlport 


volumeMounts: 

- Name: mysqldata 
mountPath: /var/lib/mysql 
volumes: 
- Name: mysqldata 

cinder: 
volumeID: e2b8d2f7-wece-90d1-a505-4acf607a90bc 
fsType: ext4 





配置 可 用 的 系统 环境 和 存储 资源 时 ， 将 其 匹配 于 资源 清单 文件 中 即 
可 完成 Pod 资 源 创建 。 另 外 ，Kubernetes 所 支持 的 各 类 持久 存储 卷 其 配置 
使 用 方式 各 有 不 同 ， 鉴 于 篇 幅 有 限 ， 这 里 不 再 一 一 列举 其 使 用 方式 。 


7.5 持久 存储 疮 


通过 前 面 使 用 持久 存储 卷 (Persistent Volume ) 的 示例 可 知 ， 
Kubernetes 用 户 必须 要 清晰 了 解 所 用 到 的 网 络 存储 系统 的 访问 细节 才能 
完成 存储 卷 相 关 的 配置 任务 ， 例 如 ，NFS 存 储 卷 的 server 和 path 字 段 的 配 
置 束 依赖 于 服务 器 地 址 和 共享 日 录 路 径 。 这 与 Kubernetes 的 同 用 户 和 开 
发 隐藏 底层 架构 的 目标 有 所 背离 ， 对 存储 资源 的 使 用 最 好 也 能 像 使 用 计 
算 资 源 一 样 ， 用 户 和 开发 人 员 无 顷 了 解 Pod 资 源 完 竟 运行 于 哪个 节点 ， 
也 无 须 了 解 存储 系统 是 什么 设备 以 及 位 于 何 处 。 为 此 ，Kubernetes 的 
PersistentVolume 子 系统 在 用 户 与 管理 员 之 间 添 加 了 一 个 抽象 屋 ， 从 而 使 
得 存储 系统 的 使 用 和 管理 职能 互相 解 耦 ， 如 图 7-4 所 示 。 


PersistentVolume (PV) 是 指 由 集群 管理 员 配 置 提 供 的 某 存 储 系 统 
上 的 一 段 存储 空间 ， 它 是 对 底层 共享 存储 的 抽象 ， 将 共享 存储 作为 一 种 
可 由 用 户 申请 使 用 的 资源 ， 实 现 了 “存储 消费 ?机制 。 通 过 存储 插件 机 
制 ，PV 文 持 使 用 多 种 网 络 存储 系统 或 云端 存储 等 多 种 后 端 存 储 系 统 ， 
例如 ， 前 面 使 用 的 NFS、RBD 和 Cinder 等 。PV 是 集群 级 别 的 资源 ， 不 属 
于 任何 名 称 空间 ， 用 户 对 PV 资源 的 使 用 需要 通过 
PersistentVolumeClaim (PVC) 提出 的 使 用 申请 (或 称 为 声明 〉 来 完成 
绑 定 ， 是 PV 资源 的 消费 者 ， 它 向 PV 申请 特定 大 小 的 空间 及 访问 模式 
(如 rw 或 ro) ， 从 而 创建 出 PVC 存 储 卷 ， 而 后 再 由 Pod 资 源 通 过 
PersistentVolumeClaim 存 储 卷 关联 使 用 ， 如 图 7-4 所 示 。 
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图 7-4 ”Pod 存储 卷 、PVC、PV 及 存储 设备 的 调用 关系 


尽管 PVC 使 得 用 户 可 以 以 抽象 的 方式 访问 存储 资源 ， 但 很 多 时 候 还 
是 会 涉及 PV 的 不 少 属性 ， 例 如 ， 用 于 不 同 场景 时 设置 的 性 能 参数 等 。 
为 此 ， 集 群 管理 员 不 得 不 通过 多 种 方式 提供 多 种 不 同 的 PV 以 满足 用 户 
不 同 的 使 用 需求 ， 两 者 衔接 上 的 偏差 必然 会 导致 用 户 的 需求 无 法 全 部 及 
时 有 效 地 得 到 满足 。Kubernetes 自 1.4 版 起 引入 了 一 个 新 的 资源 对 象 
StorageClass， 可 用 于 将 存储 资源 定义 为 具有 显著 特性 的 类 别 (Class) 
而 不 是 具体 的 PV， 例 如 “fast”slow” 或 “glod”“silver”“bronze” 等 。 用 户 通 
过 PVC 直 接 向 意向 的 类 别 发 出 申请 ， 匹 配 由 管理 员 事 先 创建 的 PV， 或 
We 0 
过 程 s 


PV 对 存储 系统 的 文 持 可 通过 其 插件 来 实现 ， 目 前 ，Kubernetes 文 持 
如 下 类 型 的 插件 。 


‘GCEPersistentDisk 








‘AWSElasticBlockStore 
‘AzureFile 


‘AzureDisk 


‘FC (Fibre Channel) ** 
‘FlexVolume 

‘Flocker 

:NFS 

iSCSI 

:RBD (Ceph Block Device) 
‘CephFS 

Cinder (OpenStack block storage) 
‘Glusterfs 

‘VsphereVolume 

‘Quobyte Volumes 
‘HostPath 

‘VMware Photon 

‘Portworx Volumes 

‘ScaleIlO Volumes 


‘StorageOS 


7.5.1 创建 PV 


PersistentVolume Spec 主 要 文 持 以 下 几 个 通用 字段 ， 用 于 定义 PV 的 
容量 、 访 问 模式 和 回收 策略 。 


1) Capacity: 当前 PV 的 容量 ， 目 前 ，Capacity 仅 文 持 空间 设 定 ， 将 
来 应 该 还 可 以 指定 IOPS 和 throughput。 


2) 访问 模式 ， 尽管 在 PV 层 看 起 来 并 无 差别 ， 但 存储 设备 支持 及 启 
用 的 功能 特性 却 可 能 不 尽 相 同 。 例 如 NFS 存 储 支 持 多 客户 端 同时 挂 载 及 
读 写 操作 ， 但 也 可 能 是 在 共享 时 仅 启用 了 只 读 操作 ， 其 他 存储 系统 也 存 
在 类 似 的 可 配置 特性 。 因 此 ，PV 底 层 的 设备 或 许 存在 其 特有 的 访问 模 
式 ， 用 户 使 用 时 必须 在 其 特性 范围 内 设 定 其 功能 ， 具 体 如 图 7-5 所 示 。 


.ReadWriteOnce: 仪 可 被 单个 节点 读 写 挂 载 ， 命令 行 中 简写 为 
RWO。 

















.ReadOnlyMany: 可 被 多 个 节点 同时 只 读 挂 载 ， 命令 行 中 简写 为 
ROX。 





-ReadWriteMany: 可 被 多 个 市 点 同时 读 写 挂 载 ;命令 行 中 简写 为 
RWX。 


3) persistentVolumeReclaimPolicy: PV 空间 被 释放 时 的 处 理 机 制 |; 
可 用 类 型 仅 为 Retain (上 默认) 、Recycle 或 Delete， 具 体 说 明 如 下 。 


“Retain: 保持 不 动 ， 由 管理 员 随 后 手动 回收 。 


-Recycle: 空间 回收 ， 即 删除 存储 卷 目录 下 的 所 有 文件 (包括 子 目 
录 和 隐藏 文件 ) ， 目 前 仅 NFS 和 hostPath 支 持 此 操作 。 


.Delete: 删除 存储 卷 ， 仅 部 分 云端 存储 系统 文 持 ， 如 AWS EBS、 
GCE PD、Azure Disk 和 Cinder。 


4) volumeMode: 卷 模 型 ， 用 于 指定 此 卷 可 被 用 作文 件 系 统 还 是 裸 
格式 的 块 设备 ， 默 认为 Filesystem。 











5) storageClassName: 当前 PV 所 属 的 StorageClass 的 名 称 ;， 默认 为 
空 值 ， 即 不 属于 任何 StorageClass。 


6) mountOptions: 挂 载 选 项 组 成 的 列表 ， 如 ro、soft 和 hard 等 。 





volume Plugin ReadWriteOnce ReadonlyMany ReadWriteMany 
AWSElasticBlockStore V 

AzureFile V V V 
AzureDisk V 

CephFS V V V 
Cinder ~ 

FC V Vv 

FlexVolume Vv V 

Flocker V 

GCEPersistentDisk ~ V 

Glusterfs V V V 
HostPath V 

iSCSI ~ V 

PhotonPersistentDIisk V 

Quobyte ~ V V 
NFS ~ V V 
RBD V V 

VsphereVolume v - - (works when pods are collocated) 
PortworxVolume V = ~ 
ScalelO ~ Vv 

StorageOS V 





图 7-5 ”各 PV 支持 的 访问 模式 


下 面 的 资源 清单 配置 示例 中 定义 了 一 个 使 用 NFS 存 储 后 端的 PV， 空 
间 大 小 为 10GB， 文 持 多 路 的 读 写 操作 。 待 后 端 存储 系统 满足 需求 时 ， 
即 可 进行 如 下 PV 资源 的 创建 : 





kind: PersistentVolume 
metadata: 
name: pv-nfs-0001 
lJabels: 
release: stable 


spec: 
capacity: 

storage: 5Gi 
volumeMode: Filesystem 
accessModes: 

- ReadwriteMany 
persistentVolumeReclaimPolicy: Recycle 
storageClassName: slow 
mountoptions : 

- hard 

- nfsvers=4.1 
nfs: 

path: "/webdata/htdocs" 

server: nfs.ilinux.io 





创建 完成 后 ， 可 以 看 到 其 状态 为 “Available"”， 即 “可 用 ?状态 ， 表 示 
目前 尚未 被 PVC 资 源 所 “ 绑 定 ”: 





~]$ kubect1 get pv pv-nfs-0001 -0 custom-columns=NAME:metadata.name,STATUS:status. 
phase 

NAME STATUS 

pv-nfs-0001 Available 





下 面 是 男 一 个 PV 资源 的 配置 清单 ， 它 使 用 RBD 存 储 后 端 ， 空 间 大 
小 为 2GB， 仅 文 持 单 个 客户 端的 读 写 访问 。 将 RBD 相 关 属 性 设 定 为 匹配 
实际 的 环境 需求 ， 例 如 在 Ceph 集 群 中 创建 映像 pv-rbd-0001， 大 小 为 
2GB， 并 在 映射 后 进行 映像 文件 格式 化 ， 随 后 即 可 创建 如 下 的 PV 资 源 : 





apiVersion: v1 
kind: PersistentVolume 
metadata: 
name: pv-rbd-0001 
spec: 
capacity: 
storage: 26Gi 
accessModes: 
- ReadwriteOnce 
rbd: 
monitors: 
- Ceph-mon01.ilinux.i0o:6789 
- Ceph-mon02.ilinux.i0o:6789 
- Ceph-mon03.ilinux.i0:6789 
pool: kube 
image: pv-rbd-0001 
user: admin 
secretRef: 
name: ceph-secret 
fsType: ext4 
readonly: false 
persistentVolumeReclaimPolicy: Retain 


i 


使 用 资源 的 查看 命令 可 列 出 PV 资源 的 相关 信息 。 创 建 完成 的 PV 资 
源 可 能 处 于 下 列 四 种 状态 中 的 某 一 种 ， 它 们 代表 着 PV 资源 生命 周期 中 
的 各 个 阶段 。 

Available: 可 用 状态 的 自由 资源 ， 尚 未 被 PVC 绑 定 。 

.Bound: 已 经 绑 定 至 某 PVC。 

Released: 绑 定 的 PVC 已 经 被 删除 ， 但 资源 尚未 被 集群 回收 。 


:Failed: 因 目 动 回收 资源 失败 而 处 于 的 故障 状态 。 


7.5.2 ”创建 PVC 


PersistentVolumeClaim 是 存储 卷 类 型 的 资源 ， 它 通过 申请 占用 某 个 
PersistentVolume 而 创建 ， 它 与 PV 是 一 对 一 的 关系 ， 用 户 无 须 关 心 其 底 
层 实 现 细节 。 申 请 时 ， 用 户 只 需要 指定 目标 空间 的 大 小 、 访 问 模式 、 
PV 标签 选择 器 和 StorageClass 等 相关 信息 即 可 。PVC 的 Spec 字 段 的 可 髓 
套 字段 具体 如 下 。 


accessMode: 当前 PVC 的 访问 模式 ， 其 可 用 模式 与 PV 相同 。 


:resources: 当前 PVC 存 储 卷 需 要 占用 的 资源 量 最 小 值 ， 目 前 ，PVC 
的 资源 限定 仅 指 其 空间 大 小 。 


“selector: 绑 定 时 对 PV 应 用 的 标签 选择 器 (matchLabels) 或 匹配 条 
件 表达 式 (matchEx- 


.pressions) ， 用 于 挑选 要 绑 定 的 PV; 如 果 同 时 指定 了 两 种 挑选 机 
制 ， 则 必须 同时 满足 两 种 选择 机 制 的 PV 才 能 被 选 出 。 


storageClassName: 所 依赖 的 存储 类 的 名 称 。 


.VolumeMode: 卷 模型 ， 用 于 指定 此 卷 可 被 用 作文 件 系 统 还 是 裸 格 
式 的 块 设备 ， 默 认为 “Filesystem”。 


volumeName: 用 于 直接 指定 要 绑 定 的 PV 的 卷 名 。 
下 面 的 配置 清单 (pvc-nfs-0001.yaml 文 件 ) 定义 了 一 个 PVC 资 源 示 


例 ， 其 选择 PV 的 挑选 机 制 是 使 用 了 标签 选择 器 ， 适 配 的 标签 是 release: 
stable， 存 储 类 为 slow， 这 会 关联 到 前 面 创建 的 PV 资 源 pv-nfs-0001: 

















apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
name: pvc-nfs-0001 
lables: 
release: “stable” 
spec: 
accessModes: 
- ReadwriteMany 
volumeMode: Filesystem 


resources: 
requests: 
storage: 5Gi 
storageClassName: slow 
selector: 
matchLabels: 
release: "stable" 





Ry 而 后 即 可 查看 其 绑 定 PV 资源 的 
日 言 恩 .: 





~]$ kubectl1 get pvc pvc-nfs-0001 
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE 
pvc-nfs-0001 Bound pv-nfs-0001 5Gi RWX Slow 6s 





如 果 需 要 绑 定 此 前 创建 的 PV 资源 pv-rbd-0001， 那 么 创建 类 似 如 下 
的 资源 配置 即 可 ， 它 将 保存 于 配置 文件 pvc-rbd-0001.yaml 中 : 








apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
name: pvc-rbd-0001 
spec: 
accessModes: 

- Readwriteonce 
volumeMode: Filesystem 
resources: 

requests: 

storage: 26Gi 
storageClassName: fast 
selector: 

matchLabels: 

release: "stable" 





0 而 后 即 可 查看 其 绑 定 PV 资源 的 
日 ; 言 恩 : 





~]$ kubectl get pvc/pvc-rbd-0001 
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE 
pvc-rbd-0001 Bound pv-rbd-0001 26Gi RWO fast 5s 





创建 好 PVC 资 源 之 后 ， 即 可 在 Pod 资 源 中 通过 persistenVolumeClain 
存储 卷 引用 它 ， 而 后 挂 载 于 容器 中 进行 数据 持久 化 。 需 要 注意 的 是 ， 
PV 是 集群 级 别 的 资源 ， 而 PVC 则 隶属 于 名 称 空 间 ， 因 此 ，PVC 在 绑 定 目 








标 PV 时 不 受 名 称 空间 的 限制 ， 但 Pod 引 用 PVC 时 ， 则 只 能 是 属于 同一 名 
称 空间 中 的 资源 。 


7.5.3 ”在 Pod 中 使 用 PVC 


在 Pod 资 源 中 调用 PVC 资 源 ， 只 需要 在 定义 volumes 时 使 用 
persistentVolumeClaims 字 段 仍 套 指定 两 个 字段 即 可 ， 有 具体 如 下 。 


claimName: 要 调用 的 PVC 存 储 卷 的 名 称 ，PVC 卷 要 与 Pod 在 同一 
名 称 空间 中 。 


TeadOnly: 是 人 否 将 存储 卷 强 制 挂 载 为 只 读 模 式 ， 默 认为 false。 
下 面 的 清单 定义 了 一 个 Pod 资 源 ， 它 是 7.4.2 节 中 直接 使 用 RBD 存 储 


的 Pod 资 源 ， 此 处 改 为 调用 了 前 面 刚刚 创建 的 名 为 pv-rbd-0001 的 PVC 资 
产 : 








apiVersion: v1 
kind: Pod 
metadata: 
name: vol-rbd-pod 
spec: 
containers: 
- name: redis 
image: redis:4-alpine 
ports: 
- containerPort: 6379 
name: redisport 
volumeMounts: 
- mountPath: /data 
name: redis-rbd-vol 
volumes: 
- name: redis-rbd-vol 
persistentVolumeClaim: 
claimName: pv-rbd-0001 











资源 创建 完成 后 ， 即 可 通过 类 似 于 此 前 7.4.1 市 示例 中 的 方式 完成 数 
据 持 久 性 测试 。 


7.5.4 存储 类 


存储 类 (storage class) 是 Kubernetes 资 源 类 型 的 一 种 ， 它 是 由 管理 
为 管理 PV 之 便 而 按 需 创 建 的 类 别 〈 膛 辑 组 ) ， 例 如 可 按 存 储 系统 的 
高 低 分 类 ， 或 者 根据 其 综合 服务 质量 级 别 进行 分 ) 类 (如 图 7-6 所 

、 依 照 备份 策略 分 类 ， 其 至 直接 按 管 理 员 自 定义 的 标准 进行 分 类 
,不 过 ， I “类别 ? 到 底 意 味 着 什么 ， 它 仅仅 是 
这 些 当 作 PV 的 特性 摘 述 


Gold Storage Class Silver Storage Class Bronze Storage Class 


局 口 口 国 UUU EBONO 
Em O00 ”加 加 中 


和 


图 7-6 基于 综合 服务 质量 的 存储 系统 分 类 


存储 类 的 好 处 之 一 便 是 支持 PV 的 动态 创建 。 用 户 用 到 持久 性 存储 
时 ， 需 要 通过 创建 PVC 来 绑 定 匹配 的 PV， 此 类 操作 需求 量 较 大 ， 或 者 
当 管 理 员 手 动 创 建 的 PV 无 法 满足 PVC 的 所 有 需求 时 ， 系 统 按 PVC 的 需求 
标准 动态 创建 适 配 的 PV 会 为 存储 管理 带 来 极 大 的 灵活 性 。 


存储 类 对 象 的 名 称 至 关 重 要 ， 它 是 用 户 调 用 的 标识 。 创 建 存 储 类 对 
象 时 ， 除 了 名 称 之 外 ， 还 需要 为 其 定义 三 个 关键 字段 : provisioner、 
parameter 和 reclaimPolicy。 


1.StorageClass Spec 


StorageClass Spec 中 的 字段 是 定义 存储 类 时 最 重要 的 字段 ， 其 包 合 
以 下 五 个 可 用 字段 。 


provisioner( 供 给 方 ): 即 提供 了 存储 资源 的 存储 系统 ， 存 储 类 要 
依赖 Provisioner 来 判定 用 使 用 的 存储 插件 以 便 适 配 到 目标 存储 系统 。 
Kubernetes 内 建 有 多 种 供给 方 ( 0 ) ， 这 些 供 给 方 的 名 字 都 
以 “kubernetes.io" 为 前 级 。 另 外 ， 它 还 支持 用 户 依 据 Kubernetes 规 范 自 定 








义 Provisioner。 


:parameters (参数 ) : 存储 类 使 用 参数 捅 述 要 关联 到 的 存储 卷 ， 不 
过 ， 不 同 的 Provisioner 可 用 的 参数 各 不 相同 。 


TeclaimPolicy: 为 当前 存储 类 动态 创建 的 PV 指 定 回 收 策略 ， 可 用 值 
为 Delete〈 默 认 ) 和 Retain; 不 过 ， 那 些 由 管理 员 手 工 创建 的 PV 的 回收 
策略 则 取决 于 它们 上 自 喘 的 定义 。 


-VolumeBindingMode: 定义 如 何 为 PVC 完 成 供给 和 绑 定 ， 默 认 值 
为 “VolumeBinding Immediate”; 此 选项 仅 在 局 用 了 存储 卷 调 度 功 能 时 才 
能 生效 。 


-mountOptions: 由 当前 类 动态 创建 的 PV 的 挂 载 选项 列表 。 
下 面 是 一 个 定义 在 glusterfs-storageclass.yaml 配 置 文 件 中 的 资源 清 


单 ， 它 定义 了 一 个 使 用 Gluster 存 储 系 统 的 存储 类 glusterfs， 并 通过 
annotations 字 段 将 其 定义 为 默认 的 存储 类 : 











kind: StorageClass 
apiVersion: storage.k8s.io/vibetali 
metadata: 
name: glusterfs 
provisioner: kubernetes.io/glusterfs 
parameters: 
resturl: "http://heketi.ilinux.io0:8080" 
restauthenabled: "false" 
restuser: "ik8s" 
restuserkey: "ik8s.io" 





这 里 需要 特别 提醒 读者 的 是 ，parameters.resturl 字 段 用 于 指定 Gluster 
存储 系统 的 RESTful 风 格 的 访问 接口 ， 本 示例 中 使 用 
的 “http://heketi.ilinux.io:8080 ”应 蔡 换 为 读者 自己 实际 环境 中 的 可 用 地 
址 。Gluster 存 储 系统 本 身 并 不 文 持 这 种 访问 方式 ， 管 理 员 需 要 额外 部 署 
heketi 配 合 Gluster 以 提供 此 类 服务 接口 。Heketi 文 持 认 证 访问 ， 不 过 只 有 
在 restauthenabled 设 置 为 “true” 时 ，restuser 和 restuserkey 字 上 段 才 会 启用 。 
Heketi 的 设置 及 使 用 方式 请 参考 附录 B。 


2. 动 态 PV 供 给 


动态 PV 供 给 的 局 用 ， 需 要 事先 由 管理 员 创 建 全 少 一 个 存储 类 ， 不 








同 的 Provisoner 的 创建 方法 各 有 不 同 ， 具 体内 容 如 前 一 节 所 示 。 为 外 ， 
并 非 所 有 的 存储 卷 插 件 都 由 Kubernetes 内 建 支 持 PV 动 态 供 给 功能 ， 具 体 
言 息 如 图 7-7 所 示 。 


上 文中 定义 glusterfs 存 储 类 资源 创建 完成 后 ， 便 可 以 据 此 使 用 动态 
PV 供给 功能 。 下 面 的 资源 清单 定义 在 pvc-gluserfs-dynamic-0001.yaml 配 
置 文件 中 ， 它 将 从 glusterfs 存 储 类 中 申请 使 用 5GB 的 存储 空间 : 








apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
name: pvc-gluster-dynamic-0001 
annotations: 
volume.beta.kubernetes,.io/storage-class: glusterfs 
spec: 
# storageClassName: "glusterfs" 
accessModes: 
- Readwriteonce 
resources: 
requests: 
storage: 56Gi 
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图 7-7 各 存储 插件 对 动态 供给 方式 的 支持 状况 


目前 ， 在 PVC 的 定义 中 指定 使 用 的 存储 类 资源 的 方式 共有 两 种 : 一 
种 是 使 用 spec.storageClassName 字 段 ， 另 一 种 证 使 
用 “volume.beta.kubernetes.io/storage-class” 注 解 信 息 ， 如 上 面 示例 中 所 
全 个 周 ， 建议 仅 使 用 一 种 方式 ， 以 免 两 者 设置 为 不 同 的 值 时 会 出 现 配 
置 错误 。 接 下 来 创建 定义 的 PVC， 并 检查 其 绑 定 状 态 : 





~]$ kubect1l create -f pvc-glusterfs-dynamic-0001.yaml 
persistentvolumeclaim "pvc-gluster-dynamic-0001" created 





通过 如 下 命令 输出 的 PVC 资 源 的 描述 信息 可 以 看 到 ，PVC 存 储 卷 已 
创建 完成 且 已 经 完成 了 PV 绑 定 ， 绑 定 的 PV 资 源 由 persistentvolume- 
controller 控 制 句 动态 提供 : 





~]$ kubectl1 describe pvc pvc-gluster-dynamic-0001 


Name : pvc-gluster-dynamic-0001 

Namespace : default 

StorageClass: glusterfs 

Status: Bound 

Volume: pvc-5836eb47-6c77-11e8-9bab-000c29be4e28 
Labels: <none> 

Annotations: pv.kubernetes.io/bind-completed=yes 


pv.kubernetes.io/bound-by-controller=yes 
volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/glusterf: 


Finalizers: [kubernetes.io/pvc-protection] 
Capacity: 5Gi 

Access Modes: RWO 

Events: 


Type Reason Age From Message 

Normal ProvisioningSucceeded 55s persistentvolume-controller Successfully 
provisioned volume pvc-5836eb47-6c77-11e8-9bab-000c29be4e28 using kubernetes. 
io/glusterfs 





任何 支持 PV 动态 供给 的 存储 系统 都 可 以 在 定义 为 存储 类 后 由 PVC 
动态 申请 使 用 ， 这 对 于 难以 事先 预 估 使 用 到 的 存储 空间 大 小 及 存储 卷 数 
量 的 使 用 场景 尤为 有 用 ， 例 如 由 StatefulSet 控 制 器 管理 Pod 对 象 时 ， 存 储 
卷 是 必 备 资源 ， 且 随 着 规模 的 变动 ， 存 储 卷 的 数量 也 会 随 之 变动 。 


另外 ， 用 户 也 可 以 使 用 云端 存储 提供 的 PV 动 态 供 给 机 制 ， 如 AWS 
EBS、AzureDisk、Cinder 或 GCEPersistentDisk 等 ， 将 Kubernetes 部 署 于 
IaaS 云 端 时 ， 此 种 存储 方式 使 用 的 较 多 。 各 类 云 存储 动态 供给 的 具体 使 
用 方式 请 参考 相关 的 使 用 手册 。 








7.5.5 PV 和 PVC 的 生命 周期 


PV 是 Kubernetes 和 集群 的 存储 资源 ， 而 PVC 则 代表 着 资源 需求 。 创 建 
PVC 时 对 PV 发 起 的 使 用 申请 ， 即 为 “ 绑 定 ”>。PV 和 PVC 是 一 一 对 应 的 关 
系 ， 可 用 于 响应 PVC 申 请 的 PV 必须 要 能 够 容纳 PVC 的 请 求 条 件 ， 它 们 二 
者 的 交互 遵循 如 下 生命 周期 。 


1. 存 储 供给 


存储 供给 (Provisioning，〉 是 指 为 PVC 准 备 可 用 PV 的 机 制 。 
Kubernetes 文 持 两 种 PV 供给 方式 静态 供给 和 动态 供给 。 


(1) 静态 供给 


静态 供给 是 指 由 集群 管理 员 手 动 创建 一 定数 量 的 PV 的 资源 供应 方 
式 。 这 些 PV 负 责 处 理 存储 系统 的 细节 ， 并 将 其 抽象 成 吻 用 的 存储 资源 
供用 户 使 用 。 毅 态 提 供 的 PV 可 能 属于 某 存 储 类 〈StorageClass) ， 也 可 
能 没有 存储 类 ， 这 一 点 取决 于 管理 员 的 设 定 。 


(2) 动态 供给 


不 存在 某 项 态 的 PV 匹 配 到 用 户 的 PVC 申 请 时 ，Kubernetes 集 群 会 党 
试 为 PVC 动 态 创建 符合 需求 的 PV， 此 即 为 动态 供给 。 这 种 方式 依赖 于 
存储 类 的 辅助 ，PVC 必 须 同 一 个 事先 存在 的 存储 类 发 起 动态 分 配 PV 的 
请 求 ， 没 有 指定 存储 类 的 PVC 请 求 会 被 禁止 使 用 动态 创建 PV 的 方式 。 


另外 ， 为 了 文 持 使 用 动态 供给 机 制 ， 集 群 管理 员 需 要 为 准 入 控制 器 
(admission controller〉 启 用 “DefaultStorageClass” 选 项 ， 这 一 点 通过 “-- 
admission-control”* 命 令 行 选项 为 API Server 进 行 设 定 即 可 ， 后 文 会 对 准 入 

控制 器 予以 描述 。 


2. 存 储 绑 定 
用 户 基 于 一 系列 存储 需求 和 访问 模式 定义 好 PVC 后 ，Kubernetes 系 


统 的 控制 器 即 会 为 其 查找 匹配 的 PV， 并 于 找到 之 后 在 此 二 者 之 间 建 立 
起 关联 关系 ， 而 后 它们 二 者 之 间 的 状态 即 转 为 " 绑 定 ”(Binding) 。 知 








PV 是 为 PVC 而 动态 创建 的 ， 则 该 PV 专用 于 其 PVC。 


若是 无 法 为 PVC 找 到 可 匹配 的 PVY， 则 PVC 将 一 直 处 于 未 绑 定 
(unbound) 状态 ， 直 到 有 符合 条 件 的 PV 出 现 并 完成 绑 定 方才 可 用 。 


(1) 存储 使 用 (Using) 


Pod 资 源 基 于 persistenVolumeClaim 卷 类 型 的 定义 ， 将 选 定 的 PVC 关 
联 为 存储 卷 ， 而 后 即 可 为 内 部 的 容器 所 使 用 。 对 于 支持 多 种 访问 模式 的 
存储 卷 来 说 ， 用 户 需 要 额外 指定 要 使 用 的 模式 。 一 旦 完成 将 存储 卷 挂 载 
至 Pod 对 象 内 的 容器 中 ， 其 应 用 即 可 使 用 关联 的 PV 提供 的 存储 空间 。 


(2) PVC 保 护 (Protection) 


为 了 避免 使 用 中 的 存储 卷 被 移 除 而 导致 数据 丢失 ，Kubernetes 目 1.9 
版 本 起 引入 了 “PVC 保 护 机 制 ?。 局 用 了 此 特性 后 ， 万 一 有 用 户 删 除了 仍 
处 于 某 Pod 资 源 使 用 中 的 PVC 时 ，Kubernetes 不 会 立即 予以 移 除 ， 而 是 推 
迟到 不 再 被 任何 Pod 资 源 使 用 后 方才 执行 删除 操作 。 处 于 此 种 阶段 的 
PVC 资 源 的 status 字 段 为 “Termination”， 并 且 其 Finalizers 字 段 中 包 
含 “kubernetes.io/pvc-protection”。 


3. 存 储 回收 〈Reclaiming ) 
完成 存储 卷 的 使 用 目标 之 后 ， 即 可 删除 PVC 对 象 以 便 进 行 资 源 回 


收 。 不 过 ， 人 至 于 如 何 操作 则 取决 于 PV 的 回收 策略 。 目 前 ， 可 用 的 回收 
策略 有 三 种 : Retained、Recycled 和 Deleted。 





(1) 留存 (Retain ) 


留存 策略 意味 着 在 删除 PVC 之 后 ，Kubernetes 系 统 不 会 目 动 删除 
PV， 而 仅仅 是 将 它 置 于 “释放 ”(released) 状态 。 不 过 ， 此 种 状态 的 PV 
尚且 不 能 被 其 他 PVC 申 请 所 绑 定 ， 因 为 此 前 的 申请 生成 的 数据 仍然 存 
在 ， 需 要 由 管理 员 手 动 决 定 其 后 续 处 理 方 案 。 这 就 意味 着 ， 如 果 想 要 再 
ee 则 需要 由 管理 员 按 下 面 的 步骤 手动 执行 删除 操 





1) 删除 PV， 这 之 后 ， 此 PV 的 数据 依然 留存 于 外 部 的 存储 之 上 。 
2) 手工 清理 存储 系统 上 依然 留存 的 数据 。 


3) 手工 删除 存储 系统 级 的 存储 卷 〈 例 如 ，RBD 人 存储 系统 上 的 
image) 以 释放 空间 ， 以 便 再 次 创建 ， 或 者 直接 将 其 重新 创建 为 PV。 


(2) 回收 (Recydle) 


如 琳 可 被 奔 层 存储 插件 支持 ， 资 源 回 收 全 上 略 会 在 存储 郑 上 执行 数据 
删除 操作 并 让 PV 资源 再 次 变 为 可 被 Claim。 男 外 ， 管 理 员 也 可 以 配置 一 
个 目 定义 的 回收 器 Pod 模 板 ， 以 便 执 行 目 定义 的 回收 操作 。 不 过 ， 此 种 
回收 生 略 行将 废弃 。 


(3) 删除 (Delete) 


对 于 支持 Deleted 回 收 策略 的 存储 插件 来 说 ， 在 PVC 被 删除 后 会 直接 
移 除 PV 对 象 ， 同 时 移 除 的 还 有 PV 相 关 的 外 部 存储 系统 上 的 存储 资产 
(asset) 。 支 持 这 种 操作 的 存储 系统 有 AWS EBS、GCE PD、Azure 
Disk 或 Cinder。 动 态 创建 的 PV 资源 的 回收 策略 取决 于 相关 存储 类 上 的 定 
义 ， 存 储 类 上 相关 的 默认 策略 为 Delete， 大 多 数 情 况 下 ， 管 理 员 都 需要 
按 用 户 期 望 的 处 理 机 制 修改 此 默认 策略 ， 以 免 导 致 数据 非 计划 内 的 误 删 
除 。 


4. 扩 展 PVC 


Kubernetes 自 1.8 版 本 起 增加 了 扩展 PV 空间 的 特性 ， 截 至 目前 ， 它 所 
支持 的 扩展 PVC 机 制 的 存储 卷 共 有 以 下 几 种 。 


‘gcePersistentDisk 

‘awsElasticBlockStore 

Cinder 

‘glusterfs 

‘rbd 

“PersistentVolumeClaimResize”; 准 入 插件 负责 对 文 持 空间 大 小 变动 的 


存储 卷 执行 更 多 的 验证 操作 ， 管 理 员 需要 事先 启用 此 插件 才能 使 用 PVC 
扩展 机 制 ， 那 些 将 “allowVolume Expansion”* 字 有 段 的 值 设置 为 “true” 的 存 





储 类 即 可 动态 扩展 存储 卷 空 间 。 随 后 ， 用 户 改动 Claim 请 求 更 大 的 空间 
即 能 触发 展 层 PV 空 间 扩展 从 而 带 来 PVC 人 存储 卷 的 扩展 。 


对 于 包含 文件 系统 的 存储 卷 来 说 ， 只 有 在 有 新 的 Pod 资 源 基 于 读 写 
模式 开始 使 用 pVC 时 才 会 执行 文件 系统 的 大 小 调整 操作 。 换 句 话说， 如 
果菜 被 扩展 的 存储 卷 已 经 由 Pod 资 源 所 使 用 ， 则 需要 重建 此 Pod 对 象 才 能 
触发 文件 系统 大 小 的 调整 操作 。 支 持 空间 调整 的 文件 系统 仅 有 XFS 和 
EXT3/EXT4。 








7.6” ”downwardAPI 存 储 卷 


很 多 时 候 ， 应 用 程序 需要 基于 其 所 在 的 环境 信息 设 定 运行 特性 等 ， 
这 类 环境 信息 包括 节点 及 集群 的 部 分 详细 属性 信息 等 ， 例 如 ，Nginx 进 
程 可 根据 节点 的 CPU 核心 数量 自动 设 定 要 局 动 的 worker 进 程 数 ，JVM 虚 
拟 机 可 根据 节点 内 存 资源 自动 设 定 其 堆 内 存 大 小 。 类 似 地 ， 托 管 运 行 于 
Kubernetes 的 Pod 对 象 中 的 容器 化 应 用 侦 尔 也 需要 获取 其 所 属 Pod 对 象 的 
IP、 主 机 名 、 标 签 、 注 解 、UID、 请 求 的 CPU 及 内 存 资源 量 及 其 限额 ， 
甚至 是 Pod 所 在 的 节点 名 称 等 ， 容 右 可 以 通过 环境 变量 或 downwardAPTI 
存储 卷 访 问 此 类 信息 ， 不 过 ， 标 签 和 注解 仅 文 持 通过 存储 卷 暴露 给 容 
3 














7.6.1 环境 变量 式 元 数据 注入 


引用 downwardAPI 元 数据 信息 的 和 用 方式 之 一 是 使 用 容 喜 的 环境 变 
量 ， 它 通过 在 valueFrom 字 上段 中 柑 套 fieldRef 或 resourceFieldRef 字 上 段 来 引 
用 相应 的 数据 源 。 不 过 ， 通 常 只 有 常量 类 的 属性 才能 够 通过 环境 变量 注 
入 到 容器 中 ， 上 毕竟 ， 在 进程 启动 完成 后 将 无 法 再 向 其 告知 变量 值 的 变 
动 ， 于 是 ， 环 境 变 量 也 就 不 支持 中 途 的 更 新 操作 。 


可 通过 fieldRef 字 段 引 用 的 信息 具体 如 下 。 














“spec.nodeName: 节点 名 称 。 

status.hostIP: 节点 IP 地 址 。 

-metadata.name: Pod 对 象 的 名 称 。 
-metadata.namespace: Pod 对 象 隶属 的 名 称 空间 。 
status.podIP: Pod 对 象 的 IP 地 址 。 


spec.serviceAccountrName: Pod 对 象 使 用 的 ServiceAccount 资 源 的 名 


:metadata.uid: Pod 对 象 的 UID。 


-metadata.labels['"<KEY>'] : Pod 对 象 标签 中 的 指定 键 的 值 ， 例 如 
metadata.labels['mylabel]， 仅 Kubernetes 1.9 及 之 后 的 版 本 才 文 持 。 


.metadata.annotations['<KEY>'] : Pod 对 象 注 解 信 息 中 的 指定 键 的 
值 ， 仅 Kubernetes 1.9 及 之 后 的 版 本 才 支 持 。 


男 外 ， 可 通过 resourceFieldRef 字 段 引用 的 信息 是 指 当 前 容器 的 资源 
请 求 及 资源 限额 的 定义 ， 因 此 它们 包括 requests.cpu、limits.cpu、 


requests.memory 和 1limits.memory 四 项 。 


下 面 的 资源 配置 清单 示例 (downwardAPI-env.yaml) 中 定义 的 Pod 
对 象 通过 环境 变量 向 容器 env-test-container 中 注入 了 Pod 对 象 的 名 称 、 隶 





属 的 名 称 空 间 、 标 和 俭 app 的 值 以 及 容器 目 身 的 CPU 资源 限额 和 内 存 资源 


二 和 和 
月 > 等 信息 : 





apiVersion: v1 
kind: Pod 
metadata: 
name: env-test-pod 
labels: 
app: env-test-pod 
spec: 
containers: 
- name: env-test-container 
image: busybox 
command: [ "/bin/sh", "-c", "env" ] 
resources: 
requests: 
memory: "32Mi" 
cpu: "125m" 
limits: 
memory: "64Mi" 
cpu: "250m" 
env: 
- Name: MY_POD_NAME 
valueFrom: 
fieldRef: 
fieldPpath: metadata.name 
- Name: MY_POD_NAMESPACE 
valueFrom: 
fieldRef: 
fieldPath: metadata.namespace 
- Name: MY_APP_LABEL 
valueFrom: 
fieldRef: 
fieldPath: metadata.1labels['app'] 
name: MY_CPU_LIMIT 
valueFrom: 
resourceFieldRef: 
resource: limits.cpu 
name: MY_MEM_ REQUEST 
valueFrom: 
resourceFieldRef: 
resource: requests.memory 
divisor: 1Mi 
restartPolicy: Never 





此 Pod 对 象 创建 完成 后 ， 同 控制 台 打 印 所 有 的 环境 变量 即 可 终止 运 
行 ， 它 仅 用 于 测试 通过 环境 变量 注入 信息 到 容 种 的 使 用 效果 : 





~]$ kubectl create -f downwardAPI-env.yaml 

pod "env-test-pod" created 

$ kubectl1 get pods -1 app=env-test-pod 

NAME READY STATUS RESTARTS AGE 
env-test-pod 0/1 Completed 0 1im 





而 后 即 可 通过 控制 全 日 志 获 取 注 入 的 环境 变量 : 





~]$ kubect1 Jogs env-test-pod | grep "^MY_" 
MY_POD_NAMESPACE=default 

MY_CPU_LIMIT=1 

MY_APP_LABEL=env-test-pod 
MY_MEM_REQUEST=32 

MY_POD_NAME=env-test-pod 








如 示例 中 的 最 后 一 个 环境 变量 所 示 ， 在 定义 资源 请 求 或 资源 限制 时 
还 可 额外 指定 一 个 “divisor”* 字 段 ， 用 于 为 引用 的 值 指 定 一 个 除数 以 实现 
所 引用 的 相关 值 的 单位 换算 。CPU 资 源 的 divisor 字 段 其 默认 值 为 1， 表 
示 为 1 个 核心 ， 相 除 的 结果 不 足 1 个 单位 时 则 癌 上 圆 整 《例如 ，0.25 癌 上 
圆 整 的 结果 为 1) ， 它 的 另 一 个 可 用 单位 为 tn， 即 表示 1 个 微 核心 。 内 
存 资 源 的 divisor 字 段 其 默认 值 为 也 是 1， 不 过 ， 它 意 指 1 个 字 节 ， 此 时 ， 
32Mi 的 内 存 资 源 则 要 换算 为 33554432 的 结果 了 予以 输出 。 其 他 可 用 的 单位 
还 有 1Ki、1Mi、1Gi 等 ， 于 是 ， 在 将 divisor 字 段 的 值 设 置 为 HIMi 时 ， 
32Mi 的 内 存 资 源 的 换算 结果 即 为 32。 


Os 未 为 容器 定义 资源 请 求 及 资源 限额 时 ，downwardAPI 
引用 的 值 即 默认 为 节点 的 可 分 配 CPU 及 内 存 资 源 量 。 


7.6.2 ”存储 郑 式 元 数据 注入 


向 容器 注入 元 数据 信息 的 另 一 种 方式 是 使 用 downwardAPI 存 储 卷 ， 
它 将 配置 的 字段 数据 映射 为 文件 并 可 通过 容器 中 的 挂 载 点 进行 访问 。 
7.2.5 节 中 能 够 通过 环境 变量 的 方式 注入 的 元 数据 信息 也 都 可 以 使 用 存储 
卷 的 方式 进行 信息 暴露 ， 除 此 之 外 ， 还 可 以 在 downwardAPI 存 储 卷 中 使 
用 fieldRef 引 用 如 下 两 个 数据 源 。 


-metadata.labels: Pod 对 象 的 所 有 标签 信息 ， 每 行 一 个 ， 格 式 为 
label-key="escaped-label-value"。 





-metadata.annotations: Pod 对 象 的 所 有 注解 信息 ， 每 行 一 个 ， 格 式 
为 annotation-key="escaped-annotation-value"。 


下 面 的 资源 配置 清单 示例 (downwardAPI-vol.yaml) 中 定义 的 Pod 
对 象 通 过 downwardAPI 存 储 卷 问 容器 volume-test-container 中 注入 了 Pod 对 
象 隶 属 的 名 称 空间 、 标 签 、 注 解 以 及 容器 自身 的 CPU 资源 限额 和 内 存 资 
源 请 求 等 信息 。 存 储 卷 在 容器 中 的 挂 载 点 为 /etc/podinfo 目 录 ， 因 此 ， 注 
入 的 每 一 项 信息 均 会 映射 为 此 路 径 下 的 一 个 文件 : 











kind: Pod 
apiVersion: v1 
metadata: 
labels: 
zone: east-china 
rack: rack-101 
app: dapi-vol-pod 
name: dapi-vol-pod 
annotations: 
annotation1: "test-value-1" 
spec: 
containers: 
- name: volume-test-container 
image: busybox 
command: ["sh", "-c", "sleep 864000"] 
resources: 


requests: 
memory: "32Mi" 
cpu: "125m" 
limits: 
memory: "64Mi" 
cpu: "250m" 
volumeMounts: 


- name: podinfo 
mountPath: /etc/podinfo 


readonly: false 
VOLumes : 
- name: podinfo 
downwardAPI: 
defaultMode: 420 
items: 
- fieldRef: 
fieldPath: metadata.namespace 
path: pod_namespace 
- fieldRef: 
fieldPath: metadata.1labels 
path: pod_labels 
- fieldRef: 
fieldPath: metadata.annotations 
path: pod_annotations 
- resourceFieldRef: 
containerName: volume-test-container 
resource: limits.cpu 
path: "cpu_limit" 
- resourceFieldRef: 
containerName: volume-test-container 
resource: requests.memory 
divisor: "1iMi" 
path: "mem_request" 





创建 资源 配置 清单 中 定义 的 Pod 对 象 后 即 可 测试 访问 由 
downwardAPI 存 储 卷 映射 的 文件 pod_namespace、pod_labels、 
pod_annotations、limits_cpu 和 mem_request 等 : 





~]$ kubectl create -f downwardAPI-vol.yaml 
pod "dapi-vol-pod" created 





人 述 的 映射 文件 ， 例 如 ， 查 看 Pod 对 象 的 标签 
列表 : 





~]$ kubect1 exec dapi-vol-pod -- cat /etc/podinfo/pod_ labels 
app="dapi-vol-pod" 

rack="rack-101" 

zone="east-china" 





如 命令 结果 所 示 ，Pod 对 象 的 标签 信息 每 行 一 个 地 映射 于 自 定 义 的 
路 径 /etc/podinfo/pod_labels 文 件 中 ， 关 似 地 ， 注 解 信 息 也 以 这 种 方式 进 
如 前 面 的 章节 中 所 述 ， 标 签 和 注解 文 持 运行 时 修改 ， 其 改动 的 
结果 也 会 实时 映射 进 downwardAPI 生 成 的 文件 中 。 例 如 ， 为 dapi-vol-pod 
添加 新 的 标签 





~]$ kubect1 label pods dapi-vol-pod env="test" 
pod "dapi-vol-pod" labeled 





而 后 再 次 查看 容器 内 的 pod_labels 文 件 的 内 容 ， 由 如 下 的 命令 结果 
可 知 新 的 标签 已 经 能 够 通过 相关 的 文件 获取 到 : 








~]$ kubect1 exec dapi-vol-pod -- cat /etc/podinfo/pod labels 
app="dapi-vol-pod" 

env="test" 

rack="rack-101" 

zone="east-china" 





downwardAPI 存 储 卷 为 Kubernetes 上 运行 容器 化 应 用 提供 了 获取 外 
部 环境 信息 的 有 效 途 径 ， 这 一 点 对 那些 非 为 云 原生 开发 的 应 用 程序 在 不 
Re 的 前 提 下 ， 获 取 环 境 信息 进行 目 身 配置 等 操作 时 尤为 有 








7.7 ”本章 小 结 


本 章 主 要 讲解 了 Kubernetes 的 存储 卷 及 其 功用 ， 并 通过 应 用 示例 给 
出 了 部 署 存 储 卷 类 型 的 使 用 方法 ， 具 体 如 下 。 


临时 存储 卷 emptyDir 和 gitRepo 的 生命 周期 与 Pod 对 象 相同 ， 但 
gitRepo 能 够 通过 引用 外 部 Git 仓 库 的 数据 来 实现 数据 的 持久 性 。 


节点 存储 大 hostPath 提 供 了 市 反 级 别 的 数据 持久 能 


:网 络 存 储 卷 NFS、GlusterFS 和 RBD 等 是 企业 内 部 较为 常用 的 独立 
部 署 的 持久 存储 系统 。 


: 云 存 储 卷 AWS ebs 等 是 托管 于 云端 的 Kubernetes 系 统 上 较为 常用 的 
持久 存储 系统 。 


-PV 和 PVC 可 将 存储 管理 和 存储 使 用 解 看 为 消费 者 模型 。 


.基于 StorageClass 可 以 实现 PV 的 动态 供给 ，GlusterFS 和 Ceph 
RBD， 以 及 云端 存储 AWS ebs 等 都 可 以 实现 此 类 功能 。 





pz DO 


第 8 章 ”配置 容 右 应 用 : ConfigMap 和 Secret 


ConfigMap 和 Secret 是 Kubernetes 系 统 上 两 种 特殊 类 型 的 存储 卷 ， 
ConfigMap 对 象 用 于 为 容器 中 的 应 用 提供 配置 数据 以 定制 程序 的 行为 ， 
不 过 敏感 的 配置 信息 ， 例 如 密 钥 、 证 书 等 通常 由 Secret 对 象 来 进行 配 
置 。 它 们 将 相应 的 配置 信息 保存 于 对 象 中 ， 而 后 在 Pod 资 源 上 以 存储 卷 
的 形式 将 其 挂 载 并 获取 相关 的 配置 ， 以 实现 配置 与 镜像 文件 的 解 厢 。 本 
章 将 主要 讲解 ConfigMap 与 Secret 存 储 卷 的 用 法 。 





8.1 容 右 化 应 用 配置 方式 


每 个 应 用 程序 都 是 一 个 可 执行 程序 文件 ， 它 包含 操作 人 码 列 表 ，CPU 
通过 执行 这 些 操作 码 来 完成 特定 的 操作 。 例 如 ，cat 命 令 是 由 /usr/bin/cat 
文件 提供 的 ， 访 文件 含有 机 器 指令 的 列表 ， 在 屏幕 上 显示 指定 文件 的 内 
容 时 需要 使 用 这 些 机 器 指令 。 几 乎 每 个 程序 的 行为 都 可 以 通过 其 命令 行 
选项 及 参数 或 配置 文件 来 按 需 定制 。 实 践 中 ， 人 们 通常 不 会 以 默认 的 配 
置 参数 运行 应 用 程序 ， 而 是 需要 根据 特定 的 环境 或 具体 的 需求 定制 其 运 
行 特性 ， 对 于 复杂 的 服务 类 应 用 程序 更 是 如 此 ， 如 Nginx、Tomcat 和 
HBase 等 ， 而 且 通 过 配置 文件 定义 其 配置 通常 是 首选 其 至 是 唯一 的 途 


大 
径 。 











那么 ， 如 何 为 容器 中 的 应 用 提供 配置 信息 呢 ? 例如 ， 为 Nginx 配 置 
一 个 特定 Server 或 指定 worker 进 程 的 数量 ， 为 Tomcat 的 JYM 配 置 其 堆 内 
存 的 大 小 等 。 传 统 实践 中 ， 通 常 有 这 么 几 种 途径 :启动 容器 时 直接 向 命 
令 传 递 参数 、 将 定义 好 的 配置 文件 便 编 码 于 〈 典 入 ) 镜像 文件 中 、 通 过 
环境 变量 (Environment Variables) 传递 配置 数据 ， 以 及 基于 Docker 卷 
传送 配置 文件 等 。 


1. 通 过 命令 行 参数 进行 配置 


Docker 容 器 可 用 来 运行 单个 应 用 程序 。 在 制作 Docker 镜 像 时 ， 
Dockerfile 中 的 ENTRYPOINT 和 和 CMD 指令 可 用 于 指定 容器 启动 时 要 运行 
的 程序 及 其 相关 的 参数 。CMD 指 令 以 列表 的 形式 指定 要 运行 的 程序 及 
其 相关 的 参数 ， 但 若 同 时 存在 ENTRYPOINT 指 令 ， 则 CMD 指 令 中 列表 
的 所 有 元 素 均 将 被 视 作 是 由 ENTRYPOINT 指 定 的 程序 的 命令 行 参数 。 
另外 ， 在 基于 某 镜 像 使 用 Docker 命 令 创 建 容器 时 ， 可 以 在 命令 行 向 
ENTRYPOINT 中 的 程序 传递 额外 的 自 定义 参数 ， 甚 至 还 可 以 修改 要 运 
J 程序 本 身 。 例 如 ， 使 用 docker run 命 令 创 建 并 启动 容器 的 格式 














docker run[OPTIONS]IMAGE[COMMAND] [ARG...] 








其 中 的 [COMMAND] 即 为 自 定 义 运 行 的 程序 ，[ARG] 则 是 传递 给 程 
序 的 参数 。 符 定义 相关 的 镜像 文件 时 使 用 了 ENTRYPOINT 指 令 ， 则 


[COMMAND] 和 [ARG] 都 会 被 当 作 命令 行 参数 传递 给 ENTRYPOINT 指 令 
中 指定 的 程序 ， 除 非 为 docker run 命 令 额外 使 用 --entrypoint 选 项 罗兰 
ENTRYPOINT 而 指定 运行 其 他 程序 。 相 关 的 使 用 详情 请 参考 Docker 的 
相关 教程 。 


在 Kubernetes 系 统 上 创建 Pod 资 源 时 ， 也 能 够 问 容 器 化 应 用 传递 命令 
行 参数 ， 甚 至 指定 运行 其 他 应 用 程序 ， 相 关 的 字段 分 别 为 
pods.spec.containers.command 和 pods.spec.containers.args。 这 一 点 在 前 面 


相关 的 革 节 中 己 有 相关 的 使 用 说 明 。 
2. 将 配置 文件 谍 入 镜像 文件 


所 谓 的 将 配置 文件 租 入 镜像 文件 ， 是 指 用 户 在 Dockerfile 中 使 用 
COPY 指 令 把 定义 好 的 配置 文件 复制 到 镜像 文件 系统 上 的 目标 位 置 ， 或 
者 使 用 RUN 指 令 调 用 sed 或 echo 一 类 的 命令 修改 配置 文件 从 而 达到 为 容 
器 化 应 用 提供 自 定义 配置 文件 之 目的 。 使 用 时 ， 奉 Docker Hub 上 的 某 镜 
像 文 件 额外 添加 配置 文件 即 能 符合 需要 ， 则 元 隆 其 Dockerfile 文 件 修 改 
0 并 由 Docker Hub 自 动 构建 出 镜像 
文件 即 可 。 


这 种 方式 的 优势 在 于 对 于 用 户 来 说 简单 易 用 ， 不 用 任何 额外 的 设 定 
就 能 启动 符合 需求 的 容器 ， 用 于 Kubernetes 环 境 亦 无 须 多 余 的 配置 。 但 
配置 文件 相关 的 任何 额外 的 修改 需求 都 不 得 不 通过 重新 构建 镜像 文件 来 
实现 ， 路 径 长 、 效 率 低 。 


3. 通 过 环境 变量 向 容器 注入 配置 信息 


通过 环境 变量 为 镜像 提供 配置 信息 是 Docker Hub 上 最 常见 的 使 用 方 
式 。 例 如 ， 使 用 MySQL 官 方 提供 的 镜像 文件 启动 MySQL 容 器 时 使 用 的 
MYSQL_ROOT_PASSWORD 环 境 变量 ， 它 用 于 为 MySQL 服 务 器 的 root 
用 户 设置 登录 密码 。 


在 基于 此 类 镜像 启动 容器 时 ， 用 户 为 docker run 命 令 通 过 -e 选 项 同 环 
境 变 量 传 值 即 能 实现 应 用 配置 ， 命 令 的 使 用 格式 为 “docker run-e 
SETTING1=foo-e SETTING2=bar...<image name>”。 启 动 时 ， 容 器 的 
ENTRYPOINT 司 动 脚本 会 抓 取 到 这 些 环 境 变 量 ， 并 在 局 动容 器 应 用 之 
前 ， 通 过 sed 或 echo 等 一 类 的 命令 将 变量 值 蔡 换 到 配置 文件 中 。 























一 般 说 来 ， 容 器 的 ENTRYPOINT 脚 本 应 该 为 这 些 环境 变量 提供 默 
认 值 ， 以 便 在 用 户 未 为 环境 变量 传 值 时 也 能 基于 此 类 需要 环境 变量 的 镜 
像 启 动容 器 。 使 用 环境 变量 这 种 配置 方式 的 优势 在 于 配置 信息 的 动态 化 
供给 ， 不 过 ， 有 些 应 用 程序 的 配置 可 能 会 复杂 到 无 法 通过 key/value 格 式 
的 环境 变量 完成 。 


另外 ， 也 可 以 让 容器 的 ENTRYPOINT 启 动 脚本 通过 网 络 中 的 K/V 存 
储 获 取 配 置 参 数 ， 和 芝 用 的 此 类 存储 系统 有 Consul 或 etcd 等 。 这 种 方式 较 
之 简单 的 环境 变量 能 够 提供 更 复杂 的 配置 信息 ， 因 为 KV 存 储 系统 支持 
多 层级 的 散 套 数据 结构 ， 有 一 些 应 用 广泛 的 数据 抓 取 工具 能 够 从 KV 存 
储 中 加 载 相关 的 数据 并 蔡 换 于 配置 文件 中 ， 甚 至 于 像 confd 这 类 的 工具 
还 能 在 KV 中 的 数据 变化 时 目 动 将 其 重 载 至 配置 文件 中 ， 这 一 点 实现 了 
ee 不 过 ， 这 种 方式 为 容器 化 应 用 引入 了 额外 的 

人 未 \ o 


Kubernetes 系 统 文 持 在 为 Pod 资 源 配置 容器 时 使 用 spec.containers.env 
为 容器 的 环境 变量 传 值 从 而 完成 应 用 的 配置 。 如 前 所 述 ， 这 种 方式 无 法 
应 付 较 复杂 的 配置 场景 ， 因 此 提供 的 配置 能 力也 很 有 限 。 


4. 通 过 存储 卷 同 容 右 注 入 配置 信息 


Docker 存 储 卷 〈volumes) 能 够 将 答 主 机 之 上 的 任何 文件 或 目录 映 
射 到 容器 文件 系统 上 ， 因 此 ， 可 以 事先 将 配置 文件 放置 于 答 主 机 之 上 的 
某 特定 路 径 中 ， 而 后 在 启动 容 右 时 进行 加 载 。 这 种 方式 灵活 易 用 ， 但 也 
依赖 于 用 户 需 要 事先 将 配置 数据 提供 在 宿主 机 上 的 特定 路 径 下 ， 而 且 在 
多 主机 模型 中 ， 寿 容器 存在 被 调度 至 任 一 主机 运行 的 可 能 性 时 ， 用 户 还 
需要 将 配置 共享 到 任 一 宿主 机 以 确保 容器 能 够 正确 地 获取 到 它们 。 


5. 借 助 Docker config 进 行 容 器 配置 


Docker swarm service 自 1.13 版 本 起 支持 使 用 secret 于 容器 之 外 保存 二 
进 制 数 据 ， 包 括 口令 、SSH 私 钥 、SSL 证 书 以 及 其 他 不 建议 通过 网 络 传 
输 或 不 应 该 在 Dockerfile 及 程序 源码 中 非 加 密 保 存 的 机 密 数 据 。 用 户 可 
0 0 这 些 数 


另外 ，Docker 自 17.06 版 本 起 为 swarm service 引 入 了 人 允许 用 户 于 容器 
之 外 存储 非 敏感 信息 (如 配置 文件 ) 的 组 件 “service config”， 从 而 支持 



































用 户 创建 通用 目的 镜像 文件 ， 并 且 不 再 需要 通过 挂 载 存 储 卷 或 使 用 环境 
变量 为 容器 提供 配置 文件 。 


Docker swarm service secret 和 config 为 容器 化 应 用 的 配置 提供 了 极 大 
的 灵活 性 ， 不 过 ， 它 们 也 只 能 应 用 于 Docker swarm service 环境 中 ， 而 不 
能 应 用 于 单独 运行 的 容器 之 上 。 


Kubernetes 系 统 也 有 类 似 的 组 件 ， 它 们 称 为 Secret 和 ConfigMap， 而 
且 是 Kubernetes 系 统 上 一 等 类 别 的 资源 对 象 ， 它 们 要 么 被 Pod 资 源 以 存储 
卷 的 形式 加 载 ， 要 么 由 容器 通过 envFrom 字 段 以 变量 的 形式 加 载 。 


8.2 ”通过 命令 行 参 数 配 置 容器 应 用 


创建 Pod 资 源 时 ， 可 以 在 容器 定义 中 目 定 义 要 运行 的 命令 以 及 为 其 
传递 的 选项 和 参数 。 在 容器 的 配置 上 下 文中 ， 使 用 command 字 段 指 定 要 
运行 的 程序 ， 而 args 字 段 则 可 用 于 指定 传递 给 程序 的 选项 及 参数 。 在 配 
置 文件 中 定义 的 command 和 args 会 覆盖 镜像 文件 中 相关 的 默认 设 定 ， 这 
类 程序 会 被 直接 运行 ， 而 不 会 由 shell 解 释 器 解释 运行 ， 因 此 与 shell 相 关 
的 特性 均 不 被 支持 ， 如 命令 行 展开 符号 {}、 重 定 问 等 操作 。 


下 面 是 定义 在 command-demo.yaml 文 件 中 的 Pod 资 源 示例 ， 它 在 容 
器 command-demo-container 中 将 busybox 镜 像 文件 中 默认 运行 的 命令 
["/bin/sh"，"-c"] 修 改 为 ["httpd"]， 并 为 其 额外 传递 了 ["-f"] 选 项 : 

















apiVersion: v1 
kind: Pod 
metadata: 
name: command-demo 
labels: 
purpose: demonstrate-command 
spec: 
containers: 
- name: command-demo-container 
image: busybox 
command: ["httpd"] 
args: ["-f"] 
ports: 
- containerPort: 80 
restartPolicy: OnFailure 





事实 上 ， 用 户 也 可 以 只 在 容器 配置 的 上 下 文中 提供 args 字 段 ， 以 实 
现 同 默认 运行 的 程序 提供 额外 的 参数 。 如 果 默 认 的 命令 为 Shell 解 释 嚣 或 
entrypoint 启 动 脚本 ， 那 么 这 些 参 数 本 身 甚 至 还 可 以 是 要 运行 的 命令 及 其 
参数 。 例 如 ， 下 面 的 容器 配置 ， 表 示 要 运行 的 程序 为 “bin/sh-c httpd- 
f”， 实 现 了 以 shell 解 释 器 解释 运行 指定 的 程序 之 目的 : 











spec: 
containers: 
- name: command-demo-container 
image: busybox 
args: ["httpd", "-f"] 
ports: 
- containerPort: 80 


二 一 


由 上 述 的 应 用 示例 可 见 ，Kubernetes 配 置 文件 中 的 command 对 应 于 
Dockerfile 中 的 ENTRYPOINT， 而 配置 文件 中 的 args 则 对 应 于 Dockerfile 
中 的 CMD。 在 Kubernetes 中 只 给 出 command 字 段 时 ， 它 会 履 靖 Dockerfile 
中 的 ENTRYPOINT 和 CMD， 只 给 出 args 字 段 时 ， 它 仅 覆 盖 CMD， 而 同 
时 给 出 command 和 args 时 ， 会 对 应 覆盖 ENTRYPOINT 和 CMD。 其 应 用 生 
效 的 示例 如 图 8-1 所 示 。 





通过 命令 行 参数 的 方式 同 容 器 应 用 传递 配置 数据 的 操作 比较 简单 ， 
但 其 功能 有 限 ， 难 以 为 应 用 生成 复杂 配置 ， 尤 其 是 那些 不 文 持 通过 命令 
行 参数 进行 的 配置 将 无 法 基于 这 种 机 制 来 实现 。 另 外 需要 注意 的 是 ， 在 
容器 创建 完成 后 ， 修 改 command 和 args 并 不 会 直接 生效 ， 除 非 重 建 Pod 对 
象 。 





ee Entrypoint Image Cmd Container command Container argS Command run 
[/ep-1] [foo bar] <not set> <not set> [ep-1 foo bar] 
[/ep-1] [foo bar] [/ep-2] <not set> [ep-2] 
[/ep-1] [foo bar] <not set> [zoo boo] [ep-1 zoo boo] 
[/ep-1] [foo bar] [/ep-2] [zo0 boo] [ep-2 zoo boo] 


图 8-1 command/args 和 HENTRYPOINT/CMD 





8.3 ”利用 环境 变量 配置 容器 应 用 


于 运行 时 配置 Docker 容 器 中 应 用 程序 的 第 二 种 方式 是 在 容器 启动 时 
问 其 传递 环境 变量 。Docker 原 生 的 应 用 程序 应 该 使 用 很 小 的 配置 文件 ， 
并 且 每 一 项 参数 都 可 由 环境 变量 或 命令 行 选项 覆盖 ， 从 而 能 够 在 运行 时 
完成 任意 的 按 需 配置 。 然 而 ， 目 前 只 有 极 少 一 部 分 应 用 程序 为 容器 环境 
原生 设计 ， 毕 竟 为 容器 原生 重 构 应 用 程序 工程 浩大 ， 且 旷日持久。 好 在 
有 通过 容器 启动 脚本 为 应 用 程序 预 设 运行 环境 的 方法 可 用 ， 通 行 的 做 法 
是 在 制作 Docker 镜 像 时 ， 为 ENTRYPOINT 指 令 定义 一 个 脚本 ， 它 能 够 
在 局 动容 器 时 将 环境 变量 蔡 换 至 应 用 程序 的 配置 文件 中 ， 而 后 再 由 此 脚 
本 启动 相应 的 应 用 程序 。 基 于 这 类 镜像 运行 容器 时 ， 即 可 通过 向 环境 变 
量 传 值 的 方式 来 配置 应 用 程序 。 


在 Kubernetes 中 使 用 此 类 镜像 启动 容器 时 ， 也 可 以 在 Pod 资 源 或 Pod 
模板 资源 的 定义 中 ， 为 容器 配置 段 使 用 env 参 数 来 定义 所 使 用 的 环境 变 
量 列表 。 事 实 上 ， 即 便 容器 中 的 应 用 本 喘 不 处 理 环 境 变 量 ， 也 一 样 可 以 
问 容 右 传递 环境 变量 ， 只 不 过 它 不 被 使 用 罢了 。 


环境 变量 配置 容器 化 应 用 时 ， 需 要 在 容器 配置 段 中 般 套 使 用 env 字 
段 ， 它 的 值 是 一 个 由 环境 变量 构建 的 列表 。 环 境 变 量 通 常 由 name 和 和 
value (或 valueFrom) 字段 构成 。 


:name<string> : 环境 变量 的 名 称 ， 必 选 字段 。 


value<string> : 环境 变量 的 值 ， 通 过 $ (VAR_NAME) 引用 ， 远 
逸 格 式 为 “$9$ (VAR_NAME) ”， 默 认 值 为 空 。 


-valueFrom<Object>: 环境 变量 值 的 引用 源 ， 例 如 ， 当 前 Pod 资 源 的 
名 称 、 名 称 空间 、 标 签 等 ， 不 能 与 非 空 值 的 value 字 段 同 时 使 用 ， 即 环境 
变量 的 值 要 么 源 于 value 字 段 ， 要 么 源 于 valueFrom 字 段 ， 二 者 不 可 同时 
提供 数据 。 


valueFrom 字 上 段 可 引用 的 值 有 多 种 来 源 ， 包 括 当 前 Pod 资 源 的 属性 
值 ， 容 器 相关 的 系统 资源 配置 、ConfigMap 对 象 中 的 Key 以 及 Secret 对 象 
中 的 Key， 它 们 应 分 别 使 用 不 同 的 藤 套 字段 进行 定义 。 




















fieldRef<Object> : 当前 Pod 资 源 的 指定 字段 ， 目 前 文 持 使 用 的 字 
段 包 括 metadataname、metadata.namespace、metadata.labels、 
metadata.annotations、spec.nodeName、 spec.serviceAccountName、 
status.hostIP 和 status.podIP。 


:configMapKeyRef<Object> : ConfigMap 对 象 中 的 特定 Key。 
“secretKeyRef<Object> : Secret 对 象 中 的 特定 Key。 


:resourceFieldRef<Object> : 当前 容 右 的 特定 系统 资源 的 最 小 值 
《配额 ) 或 最 大 值 〈 限 额 ) ， 目 前 文 持 的 引用 包括 limits.cpu、 
limits.memory、 limits.ephemeral-storage、requests.cpu、requests.memory 
和 requests.ephemeral-storage。 


下 面 是 定义 在 配置 文件 env-demo.yaml 中 的 Pod 资 源 ， 其 通过 环境 变 
量 引 用 当前 Pod 资 源 及 其 所 在 的 节点 的 相关 属性 值 配 置 容器 。fieldRef 字 
段 的 值 是 一 个 对 象 ， 它 一 般 由 apiVersion 〈 创 建 当 前 Pod 资 源 的 API 版 
本 ) 或 fieldPath 散 套 字段 所 定义 : 





apiVersion: v1 
kind: Pod 
metadata: 
name: env-demo 
labels: 
purpose: demonstrate-environment-variables 
spec: 
containers: 
- name: env-demo-container 
image: busybox 
command: ["httpd"] 
args: ["-f"] 
env: 
- Name: HELLO_WORLD 
value: just a demo 
- name: MY_NODE_NAME 
valueFrom: 
fieldRef: 
fieldPath: spec.nodeName 
- Name: MY_NODE_IP 
valueFrom: 
fieldRef: 
fieldPath: status.hostIP 
- Name: MY_POD_NAMESPACE 
valueFrom: 
fieldRef: 
fieldPath: metadata.namespace 
restartPolicy: OnFailure 


==3 


创建 上 面 资源 清单 中 定义 的 Pod 对 象 env-demo， 而 后 打印 它 的 环境 
变量 列表 、 命 令 及 其 结果 如 下 : 





~]$ kubectl1 exec env-demo printenv 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
HOSTNAME=env-demo 

MY_NODE_NAME=nodeQ02.ilinux.io 

MY_NODE_IP=172.16.0.67 

MY_POD_NAMESPACE=defauJ]t 

HELLO_WORLD=just a demo 





容器 的 启动 脚本 或 应 用 程序 调用 或 处 理 这 些 环境 变量 ， 即 可 实现 容 
器 化 应 用 的 配置 。 相 较 于 命令 行 参数 的 方式 来 次， 使 用 环境 变量 的 配置 
方式 更 清晰 、 易 懂 ， 尤 其 是 对 于 首次 使 用 相关 容器 的 用 户 来 次 ， 这 种 方 
式 能 够 快速 了 解 容 器 的 配置 方式 。 不 过 ， 这 两 种 配置 方式 有 一 个 共同 的 
缺陷 : 无 法 在 容器 应 用 运行 过 程 中 更 新 环境 变量 从 而 达到 更 新 应 用 之 目 
的 。 这 通常 意味 着 用 户 不 得 不 为 production、development 和 qa 等 不 同 的 
环境 分 别 配 置 Pod 资 源 。 好 在 ， 用 户 还 有 ConfigMap 资 源 可 用 。 

















8.4 ”应 用 程序 配置 管理 及 ConfigMap 资 源 


分 布 式 环境 中 ， 基 于 人 负载、 容错 等 需求 的 考虑 ， 儿 乎 所 有 的 服务 部 
需要 在 不 同 的 机 器 节点 上 部 署 不 止 一 个 实例 。 随 着 程序 功能 的 日 益 复 
杂 ， 程 序 的 配置 日 益 增 多 ， 而 且 配 置 文件 的 修改 频率 通常 远 远大 于 代码 
本 身 ， 这 种 情况 下 ， 有 时 仅仅 是 一 个 配置 内 容 的 修改 ， 束 不 得 不 重新 进 
行 代码 提交 到 SVGit、 打 包 、 分 发 上 线 的 流程 。 部 车 规则 较 大 的 场景 
中 ， 分 发 上 线 工 作 既 楷 杂 叉 沉 重 。 


客 其 根本 ， 所 有 的 这 些 厅 烦 都 是 由 于 配置 和 代码 在 管理 和 发 布 过 程 
中 不 加 区 分 所 致 。 配 置 本 身 源 于 代码 ， 是 为 了 提高 代码 的 元 活 性 而 提取 
出 来 的 一 些 经 常 变化 的 或 需要 定制 的 内 容 ， 而 正 是 配置 的 这 种 天 生 的 变 
化 特征 为 部 署 过 程 带 来 了 不 小 的 抹 烦 ， 也 最 终 众生 了 分 布 式 系统 配置 管 
理 系 统 ， 将 配置 内 容 从 代码 中 完全 分 离 出 来 ， 及 时 可 靠 高 效 地 提供 配置 
访问 和 更 新 服务 。 

















名 提示 。 国内 分 布 式 配置 中 心 相 关 的 开源 项 目 有 Diamond ( 阿 
里 ) 、Apollo〈 携 程 ) 、Qconf 〈 奇 虎 360) 和 disconf (百度 ) 等 。 


作为 分 布 式 系统 的 Kubernetes 也 提供 了 统一 配置 管理 方案 一 
ConfigMap 。Kubernetes 基 于 ConfigMap 对 象 实现 了 将 配置 文件 从 容器 镜 
像 中 解 称 ， 从 而 增强 了 容器 应 用 的 可 移植 性 。 简 单 来 说 ， 一 个 
ConfigMap 对 象 就 是 一 系列 配置 数据 的 集合 ， 这 些 数据 可 “注入 ”到 Pod 对 
ee 注入 方式 有 挂 载 为 存储 卷 和 传递 为 环境 变 
量 两 种 。 


ConfigMap 对 象 将 配置 数据 以 键 值 对 的 形式 进行 存储 ， 这 些 数据 可 
以 在 Pod 对 象 中 使 用 或 者 为 系统 组 件 提供 配置 ， 例 如 控制 器 对 象 等 。 不 
过 ， 无 论 应 用 程序 如 何 使 用 ConfigMap 对 象 中 的 数据 ， 用 户 都 完全 可 以 
通过 在 不 同 的 环境 中 创建 名 称 相同 但 内 容 不 同 的 ConfigMap 对 象 ， 从 而 
为 不 同 环境 中 同一 功能 的 Pod 资 源 提 供 不 同 的 配置 信息 ， 实 现 应 用 与 配 
置 的 灵活 勾兑。 


8.4.1 创建 ConfigMap 对 象 


Kubernetes 的 不 少 资源 既 可 以 使 用 kubectl create 命 令 创 建 ， 也 可 以 使 
用 清单 创建 ， 例 如 前 面 讲 到 的 namespace。ConfigMap 是 另 一 个 两 种 创建 
方式 都 比较 常用 的 资源 。 而 且 ， 通 过 使 用 “kubectl create configmap” 命 
令 ， 用 户 可 以 根据 目录 、 文 件 或 直接 值 创 建 ConfigMap 对 象 。 命 令 的 语 
法 格式 如 下 所 示 : 











kubect] create configmap<map -name><data-Source> 





其 中 ，<map-name> 即 为 ConfigMap 对 象 的 名 称 ， 而 <data-source> 是 
数据 源 ， 它 可 以 通过 直接 值 、 文 件 或 目录 来 获取 。 无 论 是 哪 一 种 数据 源 
供给 方式 ， 它 都 要 转换 为 ConfigMap 对 象 中 的 Key-Value 数 据 ， 其 中 Key 
由 用 户 在 命令 行 给 出 或 是 文件 数据 源 的 文件 名 ， 它 仪 能 由 字母 、 数 字 、 
连接 号 和 点 号 组 成 ， 而 Value 则 是 直接 值 或 文件 数据 源 的 内 容 。 


1. 利 用 直接 值 创建 
为 “kubectl create configmap” 命 令 使 用 “--from-literal* 选 项 可 在 命令 行 


直接 给 出 键 值 对 来 创建 ConfigMap 对 象 ， 重 复 使 用 此 选项 则 可 以 传递 多 
个 键 值 对 。 命 令 格式 如 下 : 














kubectl1 create configmap configmap_name --from-literal=key-name-1=value-1 





例如 ， 下 面 的 命令 创建 special-config 时 传递 了 两 个 键 值 对 : 





~]$ kubectl1 create configmap special-config \ 
--from-literal=special.how=very --from-literal=special.type=charm 





“get configmap” 命 令 可 用 于 查看 创建 的 ConfigMap 对 象 special-config 
的 相关 信息 ， 例 如 ， 如 下 的 命令 及 其 结果 : 





$ kubect1 get configmaps special-config -0 yaml 
apiVersion: v1 


data: 
special.how: very 
special.type: charm 
kind: ConfigMap 
metadata: 
creationTimestamp: 2018-03-17T05:24:562 
name: special-config 
namespace: default 
resourceVersion: "465543" 
selfLink: /api/vi/namespaces/default/configmaps/special-config 
uid: 87bibda2-29a3-11ie8-b246-000c29be4e28 





此 类 方式 提供 的 数据 量 有 限 ， 一 般 是 在 仅 通 过 有 限 的 几 个 数据 项 即 
可 为 Pod 资 源 提供 足够 的 配置 信息 时 使 用 。 


2. 基 于 文件 创建 
为 “kubectl create configmap” 命 令 使 用 “--from-file” 选 项 即 可 基于 文件 


内 容 来 创建 ConfigMap 对 象 ， 它 的 命令 格式 如 下 。 可 以 重复 多 次 使 用 “-- 
from-file” 选 项 以 传递 多 个 文件 内 容 : 





kubect] create configmap <configmap_name> --from-file=<path-to-file> 





例如 ， 下 面 的 命令 可 以 把 事先 准备 好 的 Nginx 配 置 文件 模板 保存 于 
ConfigMap 对 象 nginx-config 中 : 





~]$ kubectl create configmap nginx-config \ 
--from-file=./data/configs/nginx/conf.d/myserver.conf 





这 种 方式 创建 的 ConfigMap 对 象 ， 其 数据 存储 的 键 为 文件 路 径 的 基 
名 ， 值 为 文件 内 容 ， 例 如 下 面 命令 显示 的 nginx-config 对 象 的 信息 : 





~]$ kubectl1 get configmap nginx-config -0 yaml 
apiVersion: v1 
data: 
myserver.conf: | 
server { 
listen 8080; 
Server_name www.ilinux.io; 


include /etc/nginx/conf.d/myserver-*.cfg; 


location / { 
root /usr/share/nginx/html; 
} 


} 
kind: ConfigMap 








如 果 需 要 自行 指定 键 名 ， 则 可 在 “--from-file” 选 项 中 直接 指定 自 定义 
的 键 ， 命 令 格式 如 下 : 





kubect] create configmap <configmap_name> --from-file= <my-key-name>=<path-to-file> 





通过 这 种 方式 创建 的 ConfigMap 资 源 可 以 直接 以 键 值 形式 收纳 应 用 
程序 的 完整 配置 信息 ， 多 个 文件 可 分 别 存储 于 不 同 的 键 值 当中 。 万 外 需 
要 说 明 的 是 ， 基 于 直接 值 和 基于 文件 创建 的 方式 也 可 以 混 编 使 用 。 


3. 基 于 目录 创建 


如 果 配 置 文件 数量 较 多 有 旦 存储 于 有 限 的 目录 中 时 ，kubectl 还 提供 了 
基于 目录 直接 将 多 个 文件 分 别 收纳 为 键 值 数据 的 ConfigMap 资 源 创 建 方 
式 。 将 “--from-file” 选 项 后 面 所 跟 的 路 径 指向 一 个 目录 路 径 就 能 将 目录 下 
的 所 有 文件 一 同 创建 于 同一 ConfigMap 资 源 中 ， 命 令 格式 如 下 : 


























kubect] create configmap <configmap_name> --from-file=<path-to-directory> 





如 下 面 的 命令 ， 将 /data/configs/nginx/conf.d/ 目 录 下 的 所 有 文件 都 保 
存 于 nginx-config-files 对 象 中 : 





~]$ kubectl1 create configmap nginx-config-files --from-file=./data/configs/ 
nginx/conf.d/ 





此 目录 中 包含 myserver.conf、myserver-status.cfg 和 myserver-gzip.cfg 
三 个 配置 文件 。 创 建 ConfigMap 资 源 时 ， 它 们 会 被 分 别 存储 为 三 个 键 值 
数据 ， 如 下 面 的 命令 及 其 结果 所 示 : 





~]$ kubectl1 get cm nginx-config-files -0 yaml 
apiVersion: v1 
data: 
myserver-gzip.cfg: | 
gzip on; 
gzip_comp_level 5; 


gzip_proxied expired no-cache no-store private auth; 
gzip_types text/plain text/css application/xml text/javascript; 
myserver-status.cfg: | 
location /nginx-status { 
stub_status on; 
access_log off; 


myserver.conf: | 
server { 
listen 8080; 
server_name www.ilinux.io; 


include /etc/nginx/conf.d/myserver-*.cfg; 


location / { 
root /usr/share/nginx/html; 


} 


} 
kind: ConfigMap 





注意 ，describe 命 令 和 get-o yaml 命 令 都 可 显示 由 文件 创建 而 成 的 键 
及 其 值 ， 不 过 两 者 使 用 的 键 和 值 之 间 的 分 隔 符 不 同 。 


4. 使 用 清单 创建 
基于 配置 文件 创建 ConfigMap 资 源 时 ， 它 所 使 用 的 字段 包括 通常 的 


apiVersion、kind 和 metadata 字 段 ， 以 及 用 于 存储 数据 的 关键 字 
段 “data”。 例 如 下 面 的 示例 代码 : 





apiVersion: v1 
kind: ConfigMap 
metadata: 
name: configmap-demo 
namespace: default 
data: 
log_level: INFO 
lo0g_file: /var/log/test.1og 





如 果 其 值 来 自 于 文件 内 容 时 ， 则 使 用 配置 文件 创建 ConfigMap 资 源 
的 便捷 性 还 不 如 直接 通过 命令 行 的 方式 ， 因 此 建议 直接 使 用 命令 行 加 载 
文件 或 目录 的 方式 进行 创建 。 为 了 便于 配置 留存 ， 可 以 在 创建 完成 后 使 
用 get-o yaml 命 令 获 取 到 相关 信息 后 再 进行 编辑 留存 。 





8.4.2” 问 Pod 环 境 变 量 传递 ConfigMap 对 象 键 值 数据 


如 8.3 节 中 所 描述 的 ，Pod 资 源 的 环境 变量 值 的 获得 方式 之 一 包括 引 
用 ConfigMap 对 象 中 的 数据 ， 这 一 点 通过 在 env 字 段 中 为 valueFrom 内 埠 
configMapKeyRef 对 象 即 可 实现 ， 其 使 用 格式 如 下 : 





ValueFrom : 
configMapKeyRef : 
Key : 
name : 
optional: 





其 中 ， 字 段 name 的 值 为 要 引用 的 ConfigMap 对 象 的 名 称 ， 字 段 key 
可 用 于 指定 要 引用 ConfigMap 对 象 中 某 键 的 键 名 ， 而 字段 optional 则 用 于 
为 当前 Pod 资 源 指 明 此 引用 是 否 为 可 选 。 此 类 环境 变量 的 使 用 方式 与 直 
接 定义 的 环境 变量 并 无 区 别 ， 它 们 可 被 用 于 容器 的 启动 脚本 或 直接 传递 
给 容器 应 用 等 。 


下 面 是 保存 于 配置 文件 configmap-env.yaml 的 资源 定义 示例 ， 它 包 
含 了 两 个 资源 ， 彼 此 之 间 使 用 “---” 相 分 隔 。 第 一 个 资源 是 名 为 busybox- 
httpd-config 的 ConfigMap 对 象 ， 它 包含 了 两 个 键 值 数据 ; 第 二 个 资源 是 
名 为 configmap-env-demo 的 Pod 对 象 ， 它 通过 环境 变量 引用 了 busybox- 
httpd-config 对 象 中 的 键 值 数据 ， 并 将 其 直接 传递 给 了 上 自 定 义 运行 的 容器 
应 用 httpd: 











apiVersion: v1 

kind: ConfigMap 

metadata: 
name: busybox-httpd-config 
namespace: default 

data: 
httpd_port: "8080" 
verbose_level: "-vVv" 


apiVersion: v1 
kind: Pod 
metadata: 
name: configmap-env-demo 
namespace: default 
spec: 
containers: 
- image: busybox 
name: busybox-httpd 


command: ["/bin/httpd"] 
args: ["-f","-p","$(HTTPD_PORT)","$(HTTPD_LOG_ VERBOSE)"] 
env: 
- name: HTTPD_PORT 
ValueFrom: 
configMapKeyRef : 
name: busybox-httpd-config 
key: httpd_port 
- name: HTTPD_LOG_VERBOSE 
ValueFrom: 
configMapKeyRef : 
name: busybox-httpd-config 
key: verbose_ level 
optional: true 





注意 ， 在 command 或 args 字 上段 中 引用 环境 变量 要 使 用 “$ 
(VAR_NAME) ”的 格式 。 待 上 面 配置 文件 中 的 资源 创建 完成 后 ， 可 以 
通过 如 下 命令 验证 Pod 资 源 监听 的 端口 等 配置 信息 是 否 为 busybox-httpd- 
config 中 定义 的 内 容 : 








~]$ kubectl1 exec configmap-env-demo ps aux 
PID USER TIME COMMAND 
1 root 0:00 /bin/httpd -f -p 8080 -vv 





© 注意 ”创建 引用 了 ConfigMap 资 源 的 Pod 对 象 时 ， 被 引用 的 资 
源 必 须 事先 存在 ， 人 否则 将 无 法 局 动 相 应 的 容器 ， 直 到 被 依赖 的 资源 创建 
完成 为 止 。 不 过 ， 那 些 未 引用 不 存在 的 ConfigMap 资 源 的 容器 将 不 受 此 
影响 。 另 外 ，ConfigMap 是 名 称 空间 级 别 的 资源 ， 它 必须 与 引用 它 的 Pod 
资源 在 同一 空间 中 。 


假设 存在 这 么 一 种 情形 ， 某 ConfigMap 资 源 中 存在 较 多 的 键 值 数 
据 ， 而 全 部 或 大 部 分 的 这 些 键 值 数据 都 需要 由 容器 来 引用 。 此 时 ， 为 容 
器 逐一 配置 相应 的 环境 变量 将 是 一 件 颇 为 劳 心 费 神 之 事 ， 而 且 极 易 出 
错 。 对 此 ，Pod 资 源 文 持 在 容器 中 使 用 envFrom 字 上 段 直接 将 ConfigMap 资 
源 中 的 所 有 和 键 值 一 次 性 地 完成 导入 。 它 的 使 用 格式 如 下 : 














spec: 
containers: 
- image: some-image 
envFrom: 
- prefix <string> 
configMapRef: 
name <string> 
optional <boolean> 








enVFrom 字 段 值 是 对 象 列 表 ， 可 用 于 同时 从 多 个 ConfigMap 对 象 导 
入 键 值 数据 。 为 了 避免 从 多 个 ConfigMap 引 用 键 值 数据 时 产生 键 名 冲 
突 ， 可 以 在 每 个 引用 中 将 被 导入 的 键 使 用 prefix 字 段 指 定 一 个 特定 的 前 
组 ， 如 “HTCFG ”一 类 的 字符 串 ， 于 是 ，ConfigMap 对 象 中 的 httpd_port 
将 成 为 Pod 资 源 中 名 为 HTCFG_httpd_port 的 变量 。 





;3 加 果 键 名 中 使 用 了 连 拉线， 那么 在 转换 为 变量 名 
时 ， 连 接线 将 被 自动 蔡 换 为 下 划 线 “>”。 


例如 ， 把 上 面 示例 中 的 Pod 资 源 转 为 如 下 形式 的 定义 《configmap- 
eh i ) 后 ， 其 引用 ConfigMap 进 行 配置 的 效果 并 无 
< 同 ， 





apiVersion: v1 
kind: Pod 
metadata: 
name: configmap-envfrom-demo 
namespace: default 
spec: 
containers: 
- image: busybox 
name: busybox-httpd 
command: ["/bin/httpd"] 
args: ["-f","-p","$(HTCFG_httpd_port)","$(HTCFG_ verbose_ level)"] 
envFrom: 
- prefix: HTCFG_ 
configMapRef: 
name: busybox-httpd-config 
optional: false 





竺 Pod 资 源 创 建 完成 后 ， 可 通过 得 看 其 环境 变量 验证 其 导入 的 结 
果 : 





~]$ kubect1 exec configmap-envfrom-demo printenv 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
HOSTNAME=configmap-envfrom-demo 

HTCFG_httpd_port=8080 

HTCFG_verbose_level=-vv 





值得 提醒 的 是 ， 从 ConfigMap 对 象 寻 入 资源 时 ，Pprefix 为 可 选 字 段 ， 
省 略 时 ， 所 有 变量 名 同 ConfigMap 中 的 键 名 。 如 有 果 不 存 在 键 名 冲突 的 可 





能 性 ， 例 如 从 单个 ConfigMap 对 象 寻 入 变量 或 在 ConfigMap 对 象 中 定义 
键 名 时 已 然 添加 了 特定 的 前 级 ， 那 么 省 略 前 级 的 定义 既 不 会 导致 键 名 冲 
突 ， 又 能 保持 变量 的 简洁 。 


8.4.3 ”ConfigMap 存 储 卷 


若 ConfigMap 对 和 象 中 的 键 值 来 源 于 较 长 的 文件 内 容 ， 那 么 使 用 环境 
变量 将 其 导入 会 使 得 变量 值 占据 过 多 的 内 存 空 间 而 且 不 易 处 理 。 此 类 数 
据 通 常用 于 为 容器 应 用 提供 配置 文件 ， 因 此 将 其 内 容 直接 作为 文件 进行 
引用 方 为 较 好 的 选择 。 其 实现 方式 是 ， 在 定义 Pod 资 源 时 ， 将 此 类 
ConfigMap 对 象 配 置 为 ConfigMap 类 型 的 存储 卷 ， 而 后 由 容 右 将 其 挂 载 
至 特定 的 挂 载 点 后 直接 进行 访问 。 


1. 挂 载 整个 仓储 卷 


关联 为 Pod 资 源 的 存储 卷 时 ，ConfigMap 对 象 中 的 每 个 键 都 对 应 地 表 
现 为 一 个 文件 ， 键 名 转 为 文件 名 ， 而 键 值 则 为 相应 文件 的 内 容 ， 即 便 是 
通过 直接 值 创建 的 键 值 数据 ， 也 一 样 表 现 为 文件 视图 。 挂 载 于 容器 上 之 
后 ， 由 键 值 数 据 表现 出 的 文件 位 于 挂 载 点 目录 中 ， 容 器 中 的 进程 可 直接 
读 取 这 些 文件 的 内 容 。 


配置 Pod 资 源 时 ， 基 于 存储 卷 的 方式 引用 ConfigMap 对 象 的 方法 非常 
简单 ， 仅 需要 指明 存储 卷 名 称 及 要 引用 的 ConfigMap 对 象 名 称 即 可 。 下 
面 是 于 配置 文件 configmap-volume-pod.yaml 中 定义 的 Pod 资 源 ， 它 引用 
了 8.4.1 节 下 第 3 小 节 中 创建 的 ConfigMap 对 象 nginx-config-files， 容 器 
nginx-server 将 其 挂 载 至 应 用 程序 Nginx 加 载 配置 文件 模块 的 目 
录 /etc/nginx/conf.d 中 ， 具 体 如 下 : 




















apiVersion: v1 
kind: Pod 
metadata: 
name: configmap-volume-demo 
namespace: default 
spec: 
containers: 
- image: nginx:alpine 

name: nginx-server 

volumeMounts: 

- name: ngxconfig 
mountPath: /etc/nginx/conf.d/ 
readonly: true 

volumes: 
- name: ngxconfig 

configMap: 
name: nginx-config-files 


二 一 


此 Pod 资 源 引 用 的 nginx-config-files 中 包含 三 个 配置 文件 ， 其 中 
myserver.conf 定 义 了 一 个 虚拟 主机 www.ilinux.io ， 并 通过 include 指 令 包 
含 /etc/nginx/conf.d/ 目 录 下 以 “myserver-” 为 前 级 且 以 .cfg 为 后 级 的 所 有 配 
置 文件 ， 例 如 在 nginx-config-files 中 包含 的 myserver-status.cfg 和 myserver- 
gzip.cfg。 上 有 具 体 的 配置 内 容 请 参考 8.4.1 节 下 第 3 小 节 中 命令 的 输出 。 
ConfigMap 存 储 卷 中 的 文件 如 图 8-2 所 示 。 








nginx-config-files 











[ 


myserver.conf myserver-gzip.cfe 


myserver-status.cfg 














图 8-2 ”ConfigMap 存 储 卷 中 的 文件 


创建 此 Pod 资 源 后 于 Kubernetes 集 群 中 的 某 节点 直接 同 Pod IP 的 8080 
端口 发 起 访问 请 求 ， 即 可 验证 由 nginx-config-files 资 源 提供 的 配置 信息 
是 否 生 效 ， 例 如 ， 通 过 mginx-status 访 问 其 内 建 的 stub status: 











~]$ POD_IP=$(kubect] get pods configmap-volume-demo -0 go-template={{.status. 
podIP}}) 
~]$ curl http://${POD_IP}:8080/nginx-status 
Active connections: 1 
server accepts handled requests 
333 
Reading: © Writing: 1 Waiting: 0 





当然 ， 我 们 也 可 以 直接 于 Pod 资 源 的 相应 容器 上 执行 命令 来 确认 文 
件 是 否 存 在 于 挂 载 上 目录 中 : 





~]$ kubect1 exec configmap-volume-demo ls /etc/nginx/conf.d/ 
myserver-gzip.cfg 

myserver-status.cfg 

myserver .conf 





进一步 地 ， 还 可 以 于 容器 中 运行 Nginx 的 配置 测试 及 打印 命令 ， 确 
认 由 ConfigMap 资 源 提 供 的 配置 信息 已 然 生效 : 





~]$ kubect1 exec configmap-volume-demo -- nginx -T 
# configuration file /etc/nginx/conf.d/myserver.conf: 
server { 

listen 8080; 

server_name www.ilinux.io; 


include /etc/nginx/conf.d/myserver-*.cfg; 


location / { 
root /usr/share/nginx/html; 
} 


} 


# configuration file /etc/nginx/conf.d/myserver-gzip.cfg: 

gzip on; 

gzip_comp_level 5; 

gzip_proxied expired no-cache no-store private auth ; 
gzip_types text/plain text/css application/xml text/javascript; 


# configuration file /etc/nginx/conf.d/myserver-status.cfg: 
Jocation /nginx-status { 

stub_status on; 

access_log off; 


} 





由 上 面 两 个 命令 的 结果 可 见 ，nginx-config-files 中 的 三 个 文件 都 被 
添加 到 了 容器 中 ， 并 且 实 现 了 由 容 右 应 用 Nginx 加 载 并 生效 。 


2. 挂 载 存 储 卷 中 的 部 分 键 值 


有 了 时候 ， 用 户 很 可 能 不 期 望 在 容器 中 挂 载 某 ConfigMap 存 储 卷 后 于 
挂 载 点 目录 导出 所 有 的 文件 ， 这 在 通过 一 个 ConfigMap 对 象 为 单个 Pod 资 
源 中 的 多 个 容器 分 别提 供 配 置 时 尤其 常 见 。 例 如 前 面 的 示例 中 ， 用 户 可 
能 只 期 望 在 容器 中 挂 载 ConfigMap 存 储 卷 后 只 “导出 ”其 中 的 
myserver.conf 和 myserver-gzip.cfg， 只 提供 页 面 传输 压缩 功能 ， 而 不 输出 
nginx stub status 信 息 ， 此 时 将 其 volumes 配 置 段 改 为 如 下 所 示 的 内 容 即 
可 。 为 了 以 示 区 别 并 在 后 文中 便于 引用 及 说 明 问 题 ， 这 里 将 其 保存 于 单 
独 的 配置 文件 configmap-volume-demo-2.yaml 中 ， 并 将 Pod 资 源 命名 为 
configmap-volume-demo-2: 





apiVersion: v1 
kind: Pod 
metadata: 


name: configmap-volume-demo-2 
namespace: default 
spec: 
containers: 
- image: nginx:alpine 
name: web-server 
volumeMounts: 
- name: ngxconfig 
mountPath: /etc/nginx/conf.d/ 
readonly: true 
volumes: 
- name: ngxconfig 
configMap: 
name: nginx-config-files 
items: 
- key: myserver.conf 
path: myserver.conf 
mode: ©0644 
- key: myserver-gzip.cfg 
path: myserver-compression.cfg 





configMap 存 储 卷 的 items 字 上 段 的 值 是 一 个 对 象 列表 ， 可 髓 套 使 用 的 
字段 有 三 个 ， 具 体 如 下 。 


-key<string> : 要 引用 的 键 名 称 ， 必 选 字段 。 


path<string> : 对 应 的 键 于 挂 载 点 目录 中 生成 的 文件 的 相对 路 径 ， 
可 以 不 同 于 键 名 称 ， 必 选 字段 。 


-mode<integer>: 文件 的 权限 模型 ， 可 用 范围 为 0 到 0777。 


上 面 的 配置 示例 中 ，myserver-gzip.cfg 映 射 成 了 myserver- 
compression.cfg 文 件 ， 而 myserver.conf 则 保持 了 与 键 名 同名 ， 并 明确 指 
定 使 用 0644 的 权限 ， 从 而 达成 了 仅 装 载 部 分 文件 至 容 需 之 目的 。 


3. 独 立 挂 载 存 储 卷 中 的 键 值 


前 述 方 式 中 ， 无 论 是 装载 所 有 文件 还 是 部 分 文件 ， 挂 载 点 目录 下 原 
有 的 文件 都 会 被 隐藏 。 对 于 期 望 将 ConfigMap 对 象 提供 的 配置 文件 补充 
于 挂 载 点 目录 下 的 需求 来 说 ， 这 种 方式 显然 难以 如 愿 。 例 
如 ，/etc/nginx/conf.d 目 录 中 原本 就 存在 一 些 文件 《如 default.conf ) ， 用 
户 期 望 将 nginx-config-files 中 的 全 部 或 部 分 文件 装载 进 此 目录 中 而 不 影 
啊 其 原 有 的 文件 。 


事实 上 ， 此 种 需求 可 以 通过 此 前 第 7 章 中 曾经 于 容 右 的 























volumeMounts 字 段 中 使 用 的 subPath 字 段 来 解决 ， 它 可 以 文 持 用 户 从 存 
储 卷 挂 载 单 个 文件 或 单个 目录 而 非 整 个 存储 卷 。 例 如 ， 下 面 的 示例 残 
于 /etc/nginx/conf.d 目 录 中 单独 挂 载 了 两 个 文件 ， 而 保留 于 了 目录 下 原 有 
的 文件 。 为 了 以 示 区 别 并 在 后 文中 便于 引用 及 说 明 问 题 ， 这 里 将 其 保存 
于 单独 的 配置 文件 configmap-volume-demo-3.yaml 中 ， 并 将 Pod 资 源 命名 


为 configmap-volume-demo-3: 











apiVersion: v1 
kind: Pod 
metadata: 
name: configmap-volume-demo-3 
namespace: default 
spec: 
containers: 
- image: nginx:alpine 
name: web-server 
volumeMounts: 
- name: ngxconfig 
mountPath: /etc/nginx/conf.d/myserver.conf 
SubPath: myserver.conf 
readonly: true 
- name: ngxconfig 
mountPath: /etc/nginx/conf.,d/myserver-status,.cfg 
SubPath: myserver-status.cfg 
readonly: true 
volumes: 
- name: ngxconfig 
configMap: 
name: nginx-config-files 








基于 上 述 配 置 创建 了 Pod 资 源 之 后 ， 即 可 通过 命令 验 
证 /etc/nginx/conf.d 目 录 中 的 原 有 文件 确实 能 够 得 以 保留 ， 如 下 面 的 命令 
及 其 结果 所 示 : 








~]$ kubect1 exec configmap-volume-demo-3 Js /etc/nginx/conf.d 
default.conf 

myserver-gzip.cfg 

myserver ,conf 





8.4.4 容器 应 用 重 载 新 配置 


相 较 于 环境 变量 来 说 ， 使 用 ConfigMap 资 源 为 容器 应 用 提供 配置 的 
优势 之 一 在 于 其 支持 容器 应 用 动态 更 新 其 配置 用 户 直 接 更 新 
ConfigMap 对 象 ， 而 后 由 容器 应 用 重 载 其 配置 文件 即 可 。 


细心 的 读者 或 许 已 经 发 现 ， 挂 载 ConfigMap 存 储 卷 的 挂 载 点 目录 中 
的 文件 都 是 符 写 链接 ， 它 们 指 回 了 当前 目录 中 的 “..data”， 而 “..data” 也 是 
符号 链接 ， 它 指向 了 名 字形 如 “..2018_03_17_14_41 _41.256460087” 的 目 
录 ， 这 个 目录 才 是 存储 卷 的 真正 挂 载 点 。 例 如 ， 查 看 8.4.3 节 下 第 1 小 节 
中 创建 的 Pod 资 源 容 器 中 的 挂 载 点 中 的 文件 列表 ， 它 将 显示 出 类 似 如 下 


oe 
结 

















~]$ kubect1 exec -it configmap-volume-demo -- ls -lA /etc/nginx/conf.d 
total 0 
drwxr-xr-x 2 root root 79 Mar 17 14:41 ..2018_03_17_14 41 41.256460087 


Jrwxrwxrwx 1 root root 31 Mar 17 14:41 ..data -> ..2018_03_17_14 41 41.2564600E 

lrwxrwxrwx 1 root root 24 Mar 17 10:19 myserver-gzip.cfg -> ..data/myserver- 
gzip.cfg 

lrwxrwxrwx 1 root root 26 Mar 17 10:19 myserver-status.cfg -> ..data/myserver- 
status.cfg 


Jrwxrwxrwx 1 root root 20 Mar 17 10:19 myserver.conf -> ..data/myserver.conf 





这 样 两 级 符号 链接 设 定 的 好 处 在 于 ， 在 引用 的 ConfigMap 对 象 中 的 
数据 发 生 改 变 时 ， 它 将 被 重新 挂 载 至 一 个 新 的 临时 目录 下 ， 而 
后 “..data” 将 指 问 此 新 的 挂 载 点 ， 便 达到 了 同时 更 新 存储 卷 上 所 有 文件 数 
据 之 目的 。 例 如 ， 使 用 kubect edit 命 令 直接 在 ConfigMap 对 象 nginx- 
config-files 中 的 myserver-status.cfg 配 置 段 中 增加 “allow 
127.0.0.0/8; ”和 “deny all; "两 行 ， 而 后 再 次 查看 configmap-volume- 
demo 中 的 容器 的 挂 载 点 目录 中 的 文件 列表 ， 结 果 是 其 挂 载 点 已 经 指 问 
了 新 的 位 置 ， 例 如 下 面 的 命令 及 其 结果 所 示 : 











~]$ kubect1 exec -it configmap-volume-demo -- ls -lA /etc/nginx/conf.d 
total 0 
rwxr-xr-x 2 root root 79 Mar 17 15:17 ..2018_03_17_15_17_11.170451948 


J]rwxrwxrwx 1 root root 31 Mar 17 15:17 ..data -> ,.2018 03 17_ 15 17_11.17045194 

lJrwxrwxrwx 1 root root 24 Mar 17 10:19 myserver-gzip.cfg -> ..data/myserver- 
gzip.cfg 

Jrwxrwxrwx 1 root root 26 Mar 17 10:19 myserver-status.cfg -> ..data/myserver- 
status.cfg 


J]rwxrwxrwx 1 root root 20 Mar 17 10:19 myserver.conf -> ..data/myserver.conf 


此 时 ， 知 要 使 容器 中 应 用 程序 的 新 配置 生效 ， 则 需要 于 Pod 资 源 的 
相应 容器 上 执行 配置 重 载 操作 。 例 如 ，Nginx 可 通过 其 “nginx-s reload” 命 
令 完成 配置 文件 重 载 ， 如 下 面 的 命令 所 示 : 





~]$ kubect1 exec configmap-volume-demo -- nginx -s reload 
2018/08/17 15:18:19 [notice] 222#222: signal process started 





此 时 ， 如 果 于 此 容 占 之 外 的 位 置 访问 /nginx-status 页 面 的 请 求 是 被 拒 
绝 的 ， 则 表明 新 配置 已 然 生效 ， 如 下 面 的 命令 及 其 结果 所 示 : 





~]$ curl http://${POD_IP}:8080/nginx-status 
<html> 

<head><title>403 Forbidden</title></head> 
<body bgcolor="white"> 

<center><h1>403 Forbidden</h1i></center> 
<hr><center>nginx/1.13.9</center> 

</body> 

</html> 





然而 ， 需 要 注意 的 是 ， 对 于 不 文 持 配置 文件 重 载 操 作 的 容器 应 用 来 
说 ， 只 有 那些 在 ConfigMap 对 象 更 新 后 创建 的 Pod 资 源 中 的 容器 会 应 用 到 
新 配置 ， 此 时 如 果 不 重 局 旧 有 的 容器 ， 则 会 导致 配置 不 一 致 的 问题 。 即 
使 对 于 支持 重 载 操作 的 应 用 来 说 ， 由 于 新 的 配置 信息 并 非 同 步 推 送 进 所 
有 容器 中 ， 而 且 各 容器 的 重 载 操作 也 未 必 能 同时 进行 ， 因 此 在 更 新 时 ， 
短 时 间 内 仍然 会 存在 配置 不 一 致 的 现象 。 


另外 ， 使 用 8.4.3 下 第 3 小 节 中 的 方式 独立 挂 载 存储 孝 中 的 文件 的 容 
船 ， 其 挂 载 配置 文件 的 方式 并 非 是 以 两 级 链接 的 方式 进行 的 ， 因 此 存储 
卷 无 法 确保 所 有 挂 载 的 文件 可 以 被 同时 更 新 至 容 句 中， 因此 为 了 确保 配 
置信 息 的 一 臻 性， 目前 这 种 类 型 的 挂 载 不 支持 文件 更 新 操作 。 读 者 可 对 
此 自行 进行 验证 。 




















8.4.5 ”使 用 ConfigMap 资 源 的 注意 事项 





在 Pod 资 源 中 调用 ConfigMap 对 象 时 需要 注意 以 下 几 个 问题 。 


.以 存储 卷 方式 引用 的 ConfigMap 必 须 先 于 Pod 存 在 ， 除 非 在 Pod 中 将 
它们 全 部 标记 为 “optional*， 否 则 将 会 导致 Pod 无 法 正常 启动 的 错误 ; 同 
样 ， 即 使 存在 ConfigMap， 在 引用 的 键 不 存在 时 ， 也 会 导致 一 样 的 错 


误 。 


` 当 以 环境 变量 方式 注入 的 ConfigMap 中 的 键 不 存在 时 会 被 忽略 ， 
Pod 可 以 正常 启动 ， 但 错误 引用 的 信息 会 以 “InvalidVariableNames” 事 件 
记录 于 日 志 中 。 


-ConfigMap 是 名 称 空间 级 的 资源 ， 因 此 ， 引 用 它 的 Pod 必 须 处 于 同 
一 名 称 空间 中 。 


"kubelet 不 支持 引用 Kubernetes API Server 上 不 存 的 ConfigMap， 这 包 
括 那 些 通 过 kubelet 的 “--manifest-url” 或 “--config” 选 项 ， 以 及 kubelet REST 
API 创 建 的 Pod。 











8.5 Secret 资源 


Secret 资 源 的 功能 类 似 于 ConfigMap， 但 它 专用 于 存放 敏感 数据 ， 例 
如 密码 、 数 字 证 书 、 私 钥 、 令 牌 和 SSH key 等 。 


8.5.1 ” Secret 概述 


Secret 对 象 存储 数据 的 方式 及 使 用 方式 类 似 于 ConfigMap 对 象 ， 以 键 
值 方式 存储 数据 ， 在 Pod 资 源 中 通过 环境 变量 或 存储 卷 进行 数据 访问 。 
不 同 的 是 ，Secret 对 象 仅 会 被 分 发 至 调用 了 此 对 象 的 Pod 资 源 所 在 的 工作 
节点 ， 且 只 能 由 节点 将 其 存储 于 内 存 中 。 男 外 ，Secret 对 象 的 数据 的 存 
储 及 打印 格式 为 Base64 编 码 的 字符 串 ， 因 此 用 户 在 创建 Secret 对 象 时 也 
要 提供 此 种 编码 格式 的 数据 。 不 过 ， 在 容 右 中 以 环境 变量 或 存储 卷 的 方 
式 访问 时 ， 它 们 会 被 自动 解码 为 明文 格式 。 


需要 注意 的 是 ， 在 Master 节 点 上 ，Secret 对 象 以 非 加 密 的 格式 存储 
于 etcd 中 ， 因 此 管理 员 必 须 加 以 精心 管控 以 确保 敏感 数据 的 机 密 性 ， 必 
须 确 保 etcd 集 群 节点 间 以 及 与 API Server 的 安全 通信 ，etcd 服 务 的 访问 授 
权 ， 还 包括 用 户 访问 API Server 时 的 授权 ， 因 为 拥有 创建 Pod 资 源 的 用 户 
都 可 以 使 用 Secret 资 源 并 能 够 通过 Pod 中 的 容器 访问 其 数据 。 


Secret 对 象 主要 有 两 种 用 途 ， 一 是 作为 存储 卷 注 入 到 Pod 上 由 容 堪 应 
用 程序 所 使 用 ， 二 是 用 于 kubelet 为 Pod 里 的 容器 拉 取 镜像 时 向 私有 仓库 
提供 认证 信息 。 不 过 ， 后 面 使 用 ServiceAccount 资 源 自 建 的 Secret 对 象 是 
0 的 方式 。 通 过 ConfigMap 和 Secret 配 置 容器 的 方式 如 图 8- 
3 及 不 。 
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图 8-3 ”通过 ConfigMap 和 Secret 配 置 容 右 


Secret 资 源 主要 由 四 种 类 型 组 成 ， 具 体 如 下 。 


.Opaque: 自 定义 数据 内 容 ; base64 编 码 ， 用 来 存储 密码 、 密 钥 、 
信息 、 证 书 等 数据 ， 类 型 标识 符 为 generic。 


.kubernetes.io/service-account-token: Service Account 的 认证 信息 ， 


可 在 创建 Service Accout 时 由 Kubernetes 自 动 创建 。 


-kubernetes.io/dockerconfigjson: 用 来 存储 Docker 镜 像 仓库 的 认证 信 
上 息 ， 类 型 标识 为 docker-registry。 


:kubernetes.io/tls: 用 于 为 SSL 通 信 横 式 存 储 证 书 和 私 钥 文件 ， 命 令 
式 创建 时 类 型 标识 为 tls。 


Os base64 编 码 并 非 加 密 机 制 ， 其 编码 的 数据 可 使 
用 “base64--decode” 一 类 的 命令 进行 解码 。 


8.5.2 ”创建 Secret 资 源 


手动 创建 Secret 对 象 的 方式 有 两 种 : 通过 kubectl create 命 令 和 使 用 
Secret 配 置 文件 。 


1. 命 令 式 创建 


不 少 场景 中 ，Pod 中 的 应 用 需要 通过 用 户 名 和 和 密码 访问 其 他 服务 ， 
例如 访问 数据 库 系 统 等。 创建 此 类 的 Secret 对 象 ， 可 以 使 用 “kubectl 
create secret generic<SECRET_NAME>--from-literal=key=value” 命 令 直 接 
进行 创建 ， 不 过 为 用 户 认 证 之 需 进行 创建 时 ， 其 使 用 的 键 名 通常 是 
username 和 password。 例 如 下 面 的 命令 ， 以 “root/ikubernetes” 分 别 为 用 户 
名 和 密码 创建 了 一 个 名 为 mysql-auth 的 Secret 对 象 : 





~]$ kubect1 create secret generic mysql-auth --from-literal=username=root \ 
--from-literal=password=ikubernetes 





而 后 即 可 查看 新 建 资源 的 属性 信息 ， 由 下 面 的 命令 及 其 输出 结果 可 
以 看 出 ， 以 generic 标 识 符 创建 的 Secret 对 象 是 为 Opaque 类 型 ， 其 键 值 数 
据 会 以 Base64 的 编码 格式 进行 保存 和 打印 : 





~]$ kubectl1 get secrets mysql-auth -0 yaml 
apiVersion: v1 
data: 
password: aWt1iYmVybmVOZXM= 
Username: cm9vdA== 
kind: Secret 
metadata: 


type: Opaque 





不 过 ，Kubernetes 系 统 的 Secret 对 象 的 Base64 编 码 的 数据 并 非 加 密 格 
式 ， 许多 相关 的 工具 程序 均 可 轻松 完成 解码 ， 如 下 面 所 示 的 Base64 命 
a 








~]$ echo awtiYmVybmVOZXM= | base64 -d 
ikubernetes 








对 于 本 身 业 已 存储 于 文件 中 的 数据 ， 也 可 以 在 创建 generic 格 式 
Secret 对 象 时 使 用 “--fromc-file” 选 项 从 文件 中 直接 进行 加 载 ， 例 如 创建 用 
于 SSH 认 证 的 Secret 对 象 时 ， 如 果 疝 且 没 有 认证 信息 文件 ， 则 需要 首先 
使 用 命令 生成 一 对 认证 文件 : 





~]$ ssh-keygen -t rsa -P '' -f ${HOME}/.ssh/id_rsa 





而 后 使 用 “kubectl create secret generic<SECRET_NAME>--from- 
file[=KEY1]=/PATH/TO/FILE” 命 令 加 载 文 件 内 容 并 生成 为 Secret 对 象 : 





~]$ kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=${HOME}, 
ssh/id_rsa --from-file=ssh-publickey=${HOME}/.ssh/id_rsa.pub 





男 外 ， 车 要 基于 私 钥 和 数字 证 书 文件 创建 用 于 SSL/TLS 通 信 的 
Secret 对 象 ， 则 需要 使 用 “kubectl] create secret tls<SECRET_NAME>-- 
cert=--key=” 命 令 来 进行 ， 注 意 其 类 型 标识 符 为 TLS。 例 如 ， 假 设 需 要 为 
Nginx 测 试 创建 SSL 虚 拟 主机 ， 用 户 首 先 使 用 了 类 似 如 下 的 命令 生成 了 
私 铀 和 目 签 证 书 : 





~]$ (umask 077; openssl genrsa -out nginx,key 2048) 
~]$ openssl req -new -x509 -key nginx,key -out nginx.crt \ 
-Subj /C=CN/ST=Beijing/L=Beijing/0=DevOps/CN=www.ilinux.io 





而 后 即 可 使 用 如 下 命令 将 这 两 个 文件 创建 为 Secret 对 象 。 需 要 注意 
的 是 ， 无 论 用 户 提 供 的 证 书 和 私 钥 文件 使 用 的 是 什么 名 称 ， 它 们 一 律 会 
被 转换 为 分 别 以 tls.key〔 私 钥 〉 和 tls.crt (证 书 ) 为 其 键 名 : 





~]$ kubectl create secret tls nginx-ssl --key=./nginx.key --cert=./nginx.crt 
secret "nginx-ssl" created 





注意 其 类 型 应 该 为 “kubernetes.io/tls”"， 例 如 下 面 命令 结果 中 的 显 
四 \: 





~]$ kubectl1 get secrets nginx-ssl 
NAME TYPE DATA AGE 
nginx-ssl kubernetes.io/tls 2 37S 





由 上 述 操作 过 程 可 见 ， 命 令 式 创建 Secret 对 象 与 ConfigMap 对 象 的 方 
式 几 乎 没有 明显 区 别 。 


2. 清 单 式 创建 


Secret 资 源 是 标准 的 Kubernetes API 对 象 ， 除 了 标准 的 apiVersion、 
kind 和 metadata 字 7 段 ， 它 可 用 的 其 他 字段 具体 如 下 。 


.data<map[string]string>: “key: value” 格 式 的 数据 ， 通 常 是 敏感 信 
恩 ， 数 据 格 式 需 是 以 Base64 格 式 编 码 的 字符 串 ， 因 此 需要 用 户 事先 完成 
编码 。 


stringData<map[string]string>: 以 明文 格式 〈( 非 Base64 编 码 ) 定义 
的 “key: value” 数 据 ， 无 须 用 户 事 先 对 数据 进行 Base64 编 码 ， 而 是 在 创 
建 为 Secret 对 象 时 自动 进行 编码 并 保存 于 data 字 段 中 ; stringData 字 段 中 
的 明文 不 会 被 API Server 输 出 ， 不 过 辱 是 使 用 “kubectl apply” 命 令 进 行 的 
创建 ， 那 么 注解 信息 中 还 是 可 能 会 直接 输出 这 些 信息 的 。 


type<string>: 仅 是 为 了 便于 编程 方式 处 理 Secret 数 据 而 提供 的 类 型 
标识 。 


下 面 是 保存 于 配置 文件 secretrdemo.yaml 中 的 Secret 资 源 定义 示例 ， 
其 使 用 stringData 提 供 了 明文 格式 的 键 值 数 据 ， 从 而 免 去 了 事先 进行 手动 
编码 的 麻烦 : 























apiVersion: v1 
kind: Secret 
metadata: 
name: secret-demo 
stringData: 
username: redis 
password: redispQ@ss 
type: Opaque 





Secret 对 象 也 是 Kubernetes 系 统 的 “一 等 公民 ”， 因 此 ， 使 用 标准 资源 
创建 命令 即 可 完成 其 创建 。 相 比较 来 说 ， 基 于 清单 文件 将 保存 于 文件 中 
的 敏感 信息 创建 Secret 对 象 时 ， 用 户 首先 需要 将 敏感 信息 读 出 ， 转 为 
Base64 编 码 格式 ， 而 后 再 将 其 创建 为 清单 文件 ， 过 程 烦琐 ， 反 不 如 命令 
式 创 建 来 得 便捷 。 不 过 ， 如 果 存 在 多 次 创建 或 重 构 之 需 ， 那 么 将 其 保存 
为 配置 清单 也 是 情势 所 需 。 





8.5.3 Secret 存 储 卷 


类 似 于 Pod 消 费 ConfigMap 对 象 的 方式 ，Secret 对 象 可 以 注入 为 环境 
变量 ， 也 可 以 存储 为 卷 形式 挂 载 使 用 。 不 过 ， 容 右 应 用 通常 会 在 发 生 错 
误 时 将 所 有 环境 变量 保存 于 日 志 信 息 中 ， 甚 至 有 些 应 用 在 启动 时 即 会 将 
运行 环境 打印 到 日 志 中 ; 男 外 ， 容 器 应 用 调用 第 三 方程 序 为 子 进程 时 ， 
这 些 子 进程 能 够 继承 并 使 用 父 进程 的 所 有 环境 变量 。 有 鉴于 此 ， 使 用 环 
境 变量 引用 Secret 对 象 中 的 敏感 信息 实在 算 不 上 明智 之 举 。 


在 Pod 中 使 用 Secret 存 储 卷 的 方式 ， 除 了 其 类 型 及 引用 标识 要 蔡 换 为 
Secret 及 secretName 之 外 ， 几 乎 完全 类 似 于 ConfigMap 存 储 卷 ， 包 括 文 持 
使 用 挂 载 整个 存储 卷 、 只 挂 载 存 储 卷 中 的 指定 键 值 以 及 独立 挂 载 存 储 卷 
中 的 键 等 使 用 方式 。 


下 面 是 定义 在 配置 文件 secretrvolume-pod.yaml 中 的 Secret 资 源 使 用 
示例 ， 它 将 nginx-ssl 关 联 为 Pod 资 源 的 名 为 nginxcert 的 Secret 存 储 卷 ， 而 
后 由 容器 web-servrer 挂 载 至 /etcnginx/ssl 目 录 下 : 





























apiVersion: v1 
kind: Pod 
metadata: 

name: secret-volume-demo 

namespace: default 

spec: 

containers: 

- image: nginx:alpine 
name: web-server 
volumeMounts: 

- name: nginxcert 
mountPath: /etc/nginx/ssl1/ 
readonly: true 

volumes: 

- name: nginxcert 
secret: 

secretName: nginx-ssl 





将 上 面 资 源 清单 文件 中 定义 的 资源 创建 于 Kubernetes 系 统 上 ， 而 后 
再 查看 容器 挂 载 点 目录 中 的 文件 ， 以 确认 其 挂 载 是 否 成功 完 成 。 下 面 命 
0 私 钥 文 件 tls.key 和 证 书 文件 tls.crt 已 经 成 功 保 存 于 挂 载 点 
路 径 之 下 : 











~]$ kubect1 exec secret-volume-demo Js /etc/nginx/ssl1/ 
tls.crt 
tls.key 





此 时 ， 通过 ConfigMap 对 象 为 容器 应 用 Nginx 提 供 HTTPS 虚 拟 主机 配 
置 ， 它 只 要 使 用 由 Secret 对 象 生成 的 私 钥 和 证 书 文件 ， 即 可 定义 出 容器 
化 运行 的 Nginx 服 务 。 


8.5.4 imagePullSecret 资 源 对 象 


imagePullSecret 资 源 可 用 于 辅助 kubelet 从 需要 认证 的 私有 镜像 仓库 
获取 镜像 ， 它 通过 将 Secret 提 供 的 密码 传递 给 kubelet 从 而 在 拉 取 镜像 前 
完成 必要 的 认证 过 程 。 


使 用 imagePullSecret 的 方式 有 两 种 : 一 是 创建 docker-registry 类 型 的 
Secret 对 象 ， 并 在 定义 Pod 资 源 时 明确 通过 “imagePullSecrets” 字 段 给 出 ; 
另 一 个 是 创建 docker-registry 类 型 的 Secret 对 象 ， 将 其 添加 到 某 特 定 的 
ServiceAccount 对 象 中 ， 那 些 使 用 该 ServiceAccount 资 源 创 建 的 Pod 对 
象 ， 以 及 默认 使 用 该 ServiceAccount 的 Pod 对 象 都 将 会 直接 使 用 
imagePullSecrets 中 的 认证 信息 。 由 于 尚未 介绍 到 ServiceAccount 资 源 ， 
因此 这 里 先 介绍 第 一 种 方式 的 用 法 。 


创建 docker-registry 类 型 的 Secret 对 象 时 ， 要 使 用 “kubectl create 
secret docker-registry<SECRET NAME>--docker-user=<USERNAME>-- 
docker-password=<PASSWORD>--docker-email= 
<DOCKER_USER_EMAIL>” 的 命令 格式 ， 其 中 的 用 户 名 、 密 码 及 邮件 
言 息 是 在 使 用 docker login 命 令 登 录 时 使 用 的 认证 信息 。 例 如 ， 下 面 的 命 
令 创 建 了 名 为 local-registry 的 image pull secret 对 象 : 





~]$ kubectl create secret docker-registry local-registry --docker-username=0ps \ 
--docker-password=Opspass --docker-email=ops@ilinux.io 





此 类 Secret 对 象 打印 的 类 型 信息 为 "kubernetes.io/dockerconfigjson”， 
如 下 面 的 命令 结 采 所 示 : 





~]$ kubectl1 get secrets local-registry 
NAME TYPE DATA AGE 
local-registry kubernetes.io/dockerconfigjson 1 7S 





而 后 ， 使 用 相应 的 私有 registry 中 镜像 的 Pod 资 源 的 定义 ， 即 可 通过 
imagePullSecrets 字 段 使 用 此 Secret 对 象 ， 使 用 示例 如 下 面 的 配置 清单 所 
修 \: 





apiVersion: v1 

kind: Pod 

metadata: 
name: secret-imagepull-demo 
namespace: default 

spec: 
imagePullSecrets: 
- name: local-registry 
containers: 
- image: registry.ilinux.io/dev/myimage 

name: myapp 





上 面 的 配置 清单 仅 是 一 个 示例 ， 付 诸 运 行 时 ， 需 要 由 该 者 将 其 
Secret 中 的 内 容 及 清单 资源 的 镜像 等 信息 的 定义 修改 为 实际 可 用 的 信 


4U oO 

















试想 ， 正 在 运行 的 多 数 容器 的 镜像 均 来 自 于 私有 仓库 时 ， 为 每 个 
Pod 资 源 显 式 定 义 imagePullSecrets 实 在 不 是 一 个 好 主意 。 好 在 还 有 基于 
ServiceAccount 的 image pull secret 可 用 。 





8.6 ”本 章 小 结 


本 章 的 核心 目标 在 于 为 读者 说 明 配 置 容器 应 用 的 第 用 方式 ， 这 在 将 
同一 Pod 资 源 分 别 以 不 同 的 配置 运行 于 不 同 的 环境 中 时 特别 有 用 。 本 章 
主要 描述 了 如 下 几 种 配置 容器 化 应 用 的 方式 。 

“ 自 定 义 命令 行 选项 ， 为 容器 化 应 用 传递 特定 参数 。 


通过 环境 变量 同 容 器 注入 目 定 义 数据 。 

















基于 ConfigMap 对 象 ， 以 环境 变量 或 存储 卷 的 形式 回 容 器 提供 配置 





“借助 Secret 对 象 ， 以 存储 卷 的 形式 回 容 器 应 用 提供 敏感 信息 。 


第 9 音 ”StatefulSet 控 制 器 





应 用 程序 存在 “有 状态 ”和 “无 状态 ”两 各 类别， 因为 无 状态 类 应 用 的 
Pod 资 源 可 按 需 增加 、 减 少 或 重 构 ， 而 不 会 对 由 其 提供 的 服务 产生 除了 
并 发 啊 应 能 力 之 外 的 其 他 严重 影响 。Pod 资 源 的 常用 控制 器 中 ， 
Deployment、ReplicaSet 和 DaemonSet 等 常用 于 管理 无 状态 应 用 。 但 实际 
情况 是 ， 应 用 本 里 就 是 分 布 式 的 集群 ， 各 应 用 实例 彼此 之 间 存 在 着 关联 
关系 ， 甚 至 是 次 序 、 和 角色 方面 的 相关 性 ， 其 中 的 每 个 实例 都 有 其 自身 的 
独特 性 而 无 法 轻易 由 其 他 实例 所 取代 。 本 章 的 主要 目标 就 是 描述 专用 于 
管理 此 类 应 用 的 Pod 资 源 的 控制 器 StatefulSet。 


9.1 StatefulSet 概 述 


ReplicaSet 控 制 器 可 用 来 管控 无 状态 应 用 ， 例 如 提供 静态 内 容 服 务 
的 Web 服 务 器 程序 等 ， 而 对 于 有 状态 应 用 的 管控 ， 则 是 另 一 项 专用 控制 
器 的 任务 一 StatefulSet。 








9.1.1 _ Stateful 心 用 和 Stateless 心 用 





应 用 程序 与 用 户 、 设 备 、 其 他 应 用 程序 或 外 部 组 件 进行 通信 时 ， 根 
据 其 是 否 需要 记录 前 一 次 或 多 次 通信 中 的 相关 事件 信息 以 作为 下 一 次 通 
信 的 分 类 标准 ， 可 以 将 那些 需要 记录 信息 的 应 用 程序 称 为 有 状态 
(stateful〉 应 用 ， 而 无 须 记录 的 则 称 为 无 状态 〈stateless) 应 用 。 下 面 
我 们 先 来 了 解 下 状态 和 存储 的 关系 。 


状态 是 进程 的 时 间 属 性 。 无 状态 意味 着 一 个 进程 不 必 跟 踩 过 去 的 
交互 操作 ， 本 质 上 可 以 说 它 是 一 个 纯粹 的 功能 性 行为 。 对 应 地 ， 有 状态 
则 意味 着 进程 存储 了 以 前 交互 过 程 的 记录 ， 并 且 可 以 基于 它 对 新 的 请 求 
进行 响应。 至 于 状态 信息 被 保存 在 内 存 中 ， 或 者 持久 保存 于 磁盘 上 ， 则 


征 另外 一 个 问题 。 


存储 是 表述 持久 保存 数据 的 方法 ， 现 今 通常 是 指 机 械 硬 盘 或 SSD 设 
备 。 寿 进程 仅 需 操作 内 存 中 的 数据 ， 则 表示 其 无 须 进 行 磁盘 IO 操作 ; 
如 有 果 产 生 了 WO 操作 ， 则 通常 意味 着 数据 的 只 读 访 问 或 读 写 访问 行为 。 


如 图 9-1 所 示 ， 将 状态 和 存储 这 两 个 概念 正 交 于 坐标 系 中 ， 则 可 以 
归结 出 如 下 几 种 应 用 程序 类 型 。 
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图 9-1 ”状态 和 存储 的 关系 


象限 A 中 是 那些 具有 读 写 磁盘 需求 的 有 状态 应 用 程序 ， 如 文 持 事务 
功能 的 各 种 RDBMS 存 储 系统 ;另外 各 种 分 布 式 存 储 系 统 也 是 此 类 应 用 
程序 的 典型 ， 如 Redis Cluster、MongoDB、ZooKeeper 和 Cassandra 等 。 


象限 B 中 包含 两 类 应 用 程序 ， 一 类 是 那些 具有 读 写 磁盘 需求 的 无 状 
态 应 用 程序 ， 如 具有 千 等 性 的 文件 上 传 类 服务 程序 ， 另 一 类 是 仅 需 只 读 
类 IO 访问 的 无 状态 应 用 程序 ， 例 如 ， 从 外 部 存储 加 载 静态 资源 以 响应 
用 户 请 求 的 Web 服 务 程序 。 


-象限 C 中 是 无 磁盘 访问 需求 的 无 状态 应 用 程序 ， 如 地 理 坐 标 转换 器 





























象限 D 中 是 无 磁盘 访问 需求 的 有 状态 应 用 程序 ， 如 电子 商城 程序 中 
的 购物 车 系统 。 


不 过 ， 用 户 拥有 放置 应 用 程序 的 部 分 目 由 度 ， 例 如 ， 使 用 购物 车 的 
电子 商城 系统 中 ， 一 般 需 要 确保 购物 车 里 的 物品 在 整个 会 话 期 间 均 保持 





可 用 状态 ， 因 此 它 可 能 不 允许 使 用 纯 内 存 的 解决 方案 。 另 外 ， 设 计 有 状 
态 应 用 程序 时 需要 着重 考虑 的 另 一 个 方面 是 数据 持久 存储 的 位 置 ， 在 应 
用 程序 所 在 的 证 扣发 生 故 障 后 依然 需要 确保 数据 可 被 访问 的 场景 束 需 要 
一 个 外 部 的 持久 存储 系统 ， 否 则 使 用 市 点 本 地 存储 卷 即 可 。 














9.1.2 ”StatefulSet 控 制 器 概述 


前 面 章节 中 曾 讲 到 ，ReplicaSet 探 制 嚣 能够 从 一 个 预 置 的 Pod 模 板 创 
建 一 个 或 多 个 Pod 资 源 ， 除 了 主机 名 和 耳 地 址 等 属性 之 外 ， 这 些 Pod 资 源 
并 没有 本 质 上 的 区 别 ， 就 连 它 们 的 名 称 也 是 使 用 同一 种 散 列 模式 生成 ， 
具有 很 强 的 相似 性 。 通 常 ， 每 一 个 访问 请 求 都 会 以 与 其 他 请 求 相隔 离 的 
方式 被 这 类 应 用 所 处 理 ， 不 分 先后 也 无 须 关 心 它 们 是 否 存 在 关联 关系 ， 
哪怕 它们 先后 来 自 于 同一 个 请 求 者 。 于 是 ， 任 何 一 个 Pod 资 源 都 可 以 被 
ReplicaSet 控 制 占 重 构 出 的 新 版 本 所 蔡 代 ， 管 理 员 更 多 关注 的 也 是 它们 
的 群体 特征 ， 而 无 须 过 于 关注 任何 一 个 个 体 。 提 供 静 态 内 容 服 务 的 Web 
服务 器 程序 是 这 类 应 用 的 典型 代表 之 一 。 


对 应 地 ， 另 一 类 应 用 程序 在 处 理 客 户 问 请 求 时 ， 对 当前 请 求 的 处 理 
需要 以 前 一 次 或 多 次 的 请 求 为 基础 进行 ， 新 客户 端 发 起 的 请 求 则 会 被 其 
施加 专用 标识 ， 以 确保 其 后 续 的 请 求 可 以 被 识别 。 电 商 或 社交 等 一 类 
Web 应 用 站 点 中 的 服务 程序 通常 属于 此 类 应 用 。 男 外 还 包含 了 以 更 强 关 
联 关 系 处 理 请 求 的 应 用 ， 例 如 ，RDBMS 系 统 上 处 于 同一 个 事务 中 的 多 
个 请 求 不 但 彼此 之 间 存 在 关联 性 ， 而 且 还 要 以 严格 的 顺序 执行 。 这 类 应 
用 一 般 需 要 记录 请 求 连接 的 相关 信息 ， 即 “状态 >”， 有 的 甚至 还 需要 持久 
保存 由 请 求生 成 的 数据 ， 尤 其 是 存储 服务 类 的 应 用 ， 运 行 于 Kubernetes 
系统 上 时 需要 用 到 持久 存储 卷 。 


若 ReplicaSet 控 制 器 在 Pod 模 板 中 包含 了 某 PVC (Persistent Volume 
Claim) 的 引用 ， 则 由 它 创 建 的 所 有 Pod 资 源 都 将 共享 此 存储 卷 。PVC 后 
端的 PV 访问 模型 配置 为 Read-OnlyMany 或 ReadWriteMany 时 ， 这 些 Pod 
资源 中 的 容器 应 用 挂 载 存 储 卷 后 也 就 有 了 相同 的 数据 集 。 不 过 ， 大 多 数 
情况 是 ， 一 个 集群 系统 的 分 布 式 应 用 中 ， 每 个 实例 都 有 可 能 需要 存储 使 
用 不 同 的 数据 集 ， 或 者 各 自 拥 有 其 专 有 的 数据 副本 ， 例 如 ， 分 布 式 文件 
系统 GlusterFS 和 分 布 式 文档 存储 MongoDB 中 的 每 个 实例 各 自 使 用 专 有 
的 数据 集 ， 分 布 式 服务 框架 ZooKeeper 以 及 主 从 复制 集群 中 的 Redis 的 每 
个 实例 各 上 自 拥有 其 专用 的 数据 副本 。 由 于 ReplicaSet 控 制 占 使 用 同一 个 
模板 生成 Pod 资 源 ， 显 然 ， 它 无 法 实现 为 每 个 Pod 资 源 创建 专用 的 存储 
卷 。 别 的 可 考虑 使 用 的 方案 中 ， 目 主 式 Pod 资 源 没 有 上 自 愈 能 力 ， 而 组 织 
负责 生成 一 个 Pod 资 源 的 ReplicaSet 控 制 器 则 有 规模 扩展 不 便 的 炮 
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进一步 来 说 ， 除 了 要 用 到 专 有 的 持久 存储 卷 之 外 ， 有 些 集群 类 的 分 
布 式 应 用 实例 在 运行 期 间 还 存在 角色 上 的 差异 ， 它 们 存在 单 向 / 双 问 的 
基于 IP 地 址 或 主机 名 的 引用 关系 ， 例 如 主 从 复制 集群 中 的 MySQL 从 市 点 
对 主 贡 点 的 引用 。 这 类 应 用 实例 ， 每 一 个 都 应 当 作 一 个 独立 的 个 体 对 
待 。 ReplicaSet 对 象 控制 下 的 Pod 资 源 重 构 后 ， 其 名 称 和 IP 地 址 都 存在 变 
动 的 可 能 性 ， 因 此 也 无 法 适 配 此 种 场景 之 需 。 而 StatefulSet (有 状态 副 
本 集 ) 则 是 专门 用 来 满足 此 类 应 用 的 控制 器 类 型 ， 由 其 管 $ 控 的 每 个 Pod 
对 象 都 有 痢 固 定 的 主机 名 和 专 有 存储 卷 ， 即 便 被 重 构 后 亦 能 保持 不 变 。 


对 比 可 见 ，ReplicaSet 管 控 下 的 Pod 资 源 更 像 是 一 群 “家 

(cattle) ， 它 们 无 状态 ， 每 个 个 体 均 被 无 区 别 地 对 符 ， 因 此 也 残 可 
RD a 而 StatefulSet 控 
制 器 治 下 的 Pod 资 源 更 像 是 多 个 “宠物 ”(pet) ， 每 一 个 实例 都 有 着 其 特 
有 的 状态 ， 即 使 被 重 构 ， 也 得 与 其 半 任 坟 有 相关 的 本 于 各 汪 5 和 在 云 
原生 应 用 的 体系 里 有 两 组 常用 的 近义词 ， 第 一 组 是 无 状态 
(stateless) 、 牲 畜 〈cattle) 、 无 名 > 和 可 丢弃 
(disposable) ， 它们 都 可 用 于 表述 无 状态 应 用 。 另 一 组 是 有 状态 
Cstateful) 、 宠 物 (pet) 、 具 名 (having name) 和 不 可 丢弃 (non- 
disposable) ， 它 们 则 都 可 用 于 称呼 有 状态 应 用 。 


自 Kubernetes 1.3 起 开始 通过 PetSet 控 制 器 支持 有 状态 应 用 ， 并 于 1.5 
版 本 中 将 其 重合 名 为 StatefulSet， 支 持 每 个 Pod 对 象 一 个 专 有 索引 、 有 序 
部 署 、 有 序 终止 、 固 定 的 标识 符 及 固定 的 存储 卷 等 特性 。 不 过 在 1.9 版 
本 之 前 ， 它 一 直 处 于 beta 级 别 。 























9.1.3 ”StatefulSet 的 特性 





StatefulSet 是 Pod 资 源 控制 堪 的 一 种 实现 ， 用 于 部 晋 和 扩展 有 状态 应 
用 的 Pod 资 源 ， 确 保 它 们 的 运行 顺序 及 每 个 Pod 资 源 的 唯一 性 。 其 与 
ReplicaSet 控 制 器 不 同 的 是 ， 虽 然 所 有 的 Pod 对 象 都 其 于 同一 个 spec 配 置 
所 创建 ， 但 StatefulSet 需 要 为 每 个 Pod 维 持 一 个 唯一 且 固 定 的 标识 符 ， 必 
要 时 还 要 为 其 创建 专 有 的 存储 卷 。StatefulSet 主 要 适用 于 那些 依赖 于 下 
列 类 型 资源 的 应 用 程序 。 


-稳定 且 唯 一 的 网 络 标识 符 。 
“稳定 且 持 久 的 存储 。 

.有 序 、 优 雅 地 部 署 和 扩展 。 
.有 序 、 优 雅 地 删除 和 终止 。 
.有 序 而 自动 地 滚动 更 新 。 


般 来 说 ， 一 个 典型 、 完 整 可 用 的 StatefulSet 通 第 由 三 个 组 件 构 
成 : Headless Service、StatefulSet 和 volumeClaimTemplate。 其 中 ， 
Headless Service 用 于 为 Pod 资 源 标识 符 生 成 可 解析 的 DNS 资源 记录 ， 
StatefulSet 用 于 管控 Pod 资 源 ，volumeClaimTemplate 则 基于 静态 或 动态 的 
PV 供给 方式 为 Pod 资 源 提供 专 有 且 固 定 的 存储 。 


对 于 一 个 拥有 N 个 副本 的 StatefulSet 来 说 ， 其 Pod 对 象 会 被 有 序 创 
建 ， 顺 序 依次 是 {0...N-1}， 删 除 则 以 相反 的 顺序 进行 。 不 过 ， 
Kubernetes 1.7 及 其 之 后 的 版 本 也 支持 并 行 管理 Pod 对 象 的 策略 。Pod 资 源 
的 名 称 格式 为 $ (statefulset name)〉-$ 《ordinal〉， 例 如 ， 名 称 为 Web 的 
ReplicaSet 资 源 所 生成 的 Pod 对 象 的 名 称 依次 为 web-0、web-1、web-2 
等 ， 其 域名 后 级 可 由 相关 的 Headless 类 型 的 Service 资 源 给 出 ， 格 式 为 $ 
(service name ) .$ (namespace) .svc.cluster.local，cluster.local 是 集群 默 


认 使 用 的 域名 。 


ReplicaSet 控 制 器 会 为 每 个 VolumeClaim 模 板 创建 一 个 专用 的 PV， 
它 会 从 模板 中 指定 的 StorageClass 中 为 每 个 PVC 创 建 PV， 未 指定 时 将 使 


























用 默认 的 StorageClass 资 源 ， 而 如 果 存 储 系 统 不 支持 PV 的 动态 供给 ， 就 
需要 管理 员 事 先 创 建 好 满足 需求 的 所 有 PV。 删 除 Pod 资 源 甚 至 是 
ReplicaSet 控 制 器 并 不 会 删除 与 其 相关 的 PV 资源 以 确保 数据 安全 ， 它 需 
要 由 用 户 手动 删除 。 这 也 意味 着 ，Pod 资 源 被 重新 调度 至 其 他 节点 时 ， 
其 PV 及 数据 可 复 用 。Pod 名 称 、PVC 和 PV 关 系 如 图 9-2 所 示 。 


ReplicaSet 也 文 持 规模 扩 缩 容 操作 ， 扩 容 意 味 痢 按 索 引 顺 序 增 加 更 
多 的 Pod 资 源 ， 而 缩 容 则 表示 按 逆 序 依次 删除 索引 号 最 大 的 Pod 资 源 直 到 
规模 数量 满足 目标 设 定 值 。 执 行 扩容 操作 时 ， 应 用 至 菜 Pod 对 象 之 前 必 
须 确保 其 前 的 每 个 Pod 对 象 都 已 经 就 绪 ， 反 之 ， 终 止 一 个 Pod 对 象 时 ， 必 
须 事先 确保 它 的 后 继 者 已 经 终止 完成 。 考 虑 到 不 少 的 有 状态 应 用 不 支持 
规模 的 安全 快速 缩减 ， 因 此 ，ReplicaSet 控 制 器 不 支持 缩 容 时 的 并 行 操 
作 ， 一 次 仪 能 终止 一 个 Pod 资 源 ， 以 免 导 致 数据 率 误 。 这 通 第 也 意味 
者 ， 存 在 错误 的 未 恢复 的 Pod 资 源 时 ，ReplicaSet 控 制 器 也 会 拒绝 局 动 纵 
容 操作 。 此 外 ， 缩 容 操作 导致 的 Pod 资 源 终 止 也 不 会 删除 与 其 相关 的 
PV， 以 确保 数据 安全 。 


StatefulSet web 1 BE pve se ,| ee 
Be A 


template : a | 四 
| Pod web-1 PVCweb-l mm pV 
、 
| volumeClaim 
template aa 一 i 
! | Pod web-2 PVC web-2 [py 


图 9-2 ”Pod 名 称 、PVC 和 PV 


Kubernetes 上 自 1.7 版 本 起 还 文 持 用 户 自 定义 更 新 策略 ， 该 版 本 兼容 文 

持 之 前 版 本 中 的 删除 后 更 新 〈OnDelete) 策略 ， 以 及 新 的 滚动 更 新 策略 
CRollingUpdate) 。OnDelete 意 味 着 ReplicaSet 不 会 自动 更 新 Pod 资 源 除 

非 它 被 删除 而 激活 重建 操作 。RollingUpdate 是 默认 的 更 新 策略 ， 它 文 持 
Pod 资 源 的 自动 、 滚 动 更 新 。 更 新 顺序 与 终止 Pod 资 源 的 顺序 相同 ， 由 索 
引号 最 大 的 资源 开始 ， 终 止 一 个 并 完成 其 更 新 ， 而 后 更 新 下 一 个 。 另 
外 ，RollingUpdate 还 支持 分 区 (partition) 机 制 ， 用 户 可 基于 某 个 用 于 
分 区 的 索引 号 对 Pod 资 源 进 行 分 区 ， 所 以 大 于 等 于 此 索引 号 的 Pod 资 源 会 
被 深 动 更 新 ， 如 图 9-3 所 示 。 而 小 于 此 索引 号 的 Pod 资 源 则 不 会 被 更 新 ， 
即便 是 此 范围 内 的 某 Pod 资 源 被 删除 ， 它 也 一 样 会 被 基于 旧版 本 的 Pod 模 





























































板 重 建 。 


StatefulSet web 


partition=3 
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图 9-3 ”ReplicaSet 分 区 滚动 更 新 


知 给 定 的 分 区 号 大 于 副本 数量 ， 则 意味 着 不 会 有 Pod 资 源 索 引号 大 
于 此 分 区 号 ， 所 有 的 Pod 资 源 均 不 会 被 更 新 ， 对 于 暂 存 太 布 、 金 丝 八 发 
布 或 分 段 发 布 来 说 ， 这 也 是 有 用 的 设 定 。 





9.2 ”StatefulSet 基 础 应 用 


本 节 将 基于 StorageClass 及 其 相关 的 PV 动 态 供给 功能 创建 一 个 
stateful 资 源 示例 ， 并 验证 它 的 各 种 特性 。 


9.2.1 创建 StatefulSet 对 象 


如 前 所 述 ， 一 个 完整 的 StatefulSet 控 制 器 需要 由 一 个 Headless 
Service、 一 个 StatefulSet 和 一 个 volumeClaimTemplate 组 成 。 其 中 ， 
Headless Service 用 于 为 Pod 资 源 标识 符 生 成 可 解析 的 DNS 资源 记录 ， 
StatefulSet 用 于 管控 Pod 资 源 ，volumeClaimTemplate 则 其 于 静态 或 动态 的 
0 且 固 定 的 存储 ， 如 下 面 的 资源 清单 中 的 
定义 所 示 : 








apiVersion: v1 
kind: Service 


metadata: 
name: myapp-svc 
labels: 
app: myapp-svc 
spec: 
ports: 
- port: 80 
name: web 
clusterIP: None 
selector: 


app: myapp-pod 
apiVersion: apps/v1 
kind: Statefu1lSet 
metadata: 
name: myapp 
spec: 
serviceName: myapp-svc 
replicas: 2 
selector: 
matchLabels: 
app: myapp-pod 
template: 
metadata: 
labels: 
app: myapp-pod 
spec: 
Containers : 
- name: myapp 
image: ikubernetes/myapp:v5 
ports: 
- containerPort: 80 
name: web 
volumeMounts: 
- name: myappdata 
mountPath: /usr/share/nginx/html 
volumeClaimTemplates: 
- metadata: 
name: myappdata 
spec: 


accessModes: [ "ReadwriteOnce" | 
storageClassName: "gluster-dynamic" 
resources: 
requests: 
storage: 26Gi 





上 面 示例 中 的 配置 定义 在 statefulset-demo.yaml 文 件 中 。 由 于 
StatefulSet 资 源 依赖 于 一 个 事先 存在 的 Headless 类 型 的 Service 资 源 ， 
此 ， 这 里 首先 定义 了 一 个 名 为 myapp-svc 的 Headless Service 资 源 ， 用 于 
为 关联 到 的 每 个 Pod 资 源 创建 DNS 资源 记录 。 接 着 定义 了 一 个 名 为 
myapp 的 StatefulSet 资 源 ， 它 通过 Pod 模 板 创建 了 两 个 Pod 资 源 副 本 ， 并 
基于 volumeClaimTemplates〈 存 储 卷 申请 模板 ) 回 gluster-dynamic 存 储 类 
请 求 动态 供给 PV， 从 而 为 每 个 Pod 资 源 提供 大 小 为 2GB 的 专用 存储 卷 。 


事实 上 ， 定 义 StatefulSet 资 源 时 ，spec 中 必须 要 骸 套 的 字段 
为 “serviceName” 和 “template”， 用 于 指定 关联 的 Headless Service 和 要 使 
用 的 Pod 模 板 , “volumeClaimTemplates” 


字段 用 于 为 Pod 资 源 创 建 专 有 存储 卷 PVC 模 板 ， 它 可 内 骸 使 用 的 字 
段 即 为 persistentVolume-Claim 资 源 的 可 用 字段 ， 对 StatefulSet 资 源 为 可 
在 依赖 的 存储 类 满足 条 件 之 后 ， 即 可 创建 清单 中 定义 的 相关 资源 : 








~]$ kubectl apply -f statefulset-demo.yaml 
service "myapp-svc" created 
statefulset.apps "myapp" created 





默认 情况 下 ，StatefulSet 控 制 器 以 串 行 的 方式 创建 各 Pod 副 本 ， 如 果 
想 要 以 并 行 方 式 创建 和 删除 Pod 资 源 ， 则 可 以 设 
定 .spec.podManagementPolicy 字 上 段 的 值 为 “Parallel”*， 默 认 值 
为 “OrderedReady”。 使 用 默认 的 顺序 创建 策略 时 ， 可 以 使 用 下 面 的 命令 
观察 相关 Pod 资 源 的 顺 次 生成 过 程 : 








~]$ kubectl1 get pods -1 app=myapp-pod -w 
S 


NAME READY STATU RESTARTS AGE 
myapp-0 0/1 Pending 0 Os 
myapp-0 0/1 ContainerCreating 0 Os 
myapp-0 1/1 Running 0 42S 
myapp-1 0/1 Pending 0 Os 
myapp-1 0/1 ContainerCreating 0 Qs 


myapp-1 1/1 Running 0 14S 





待 所 有 的 Pod 资 源 都 创建 完成 之 后 ， 可 以 在 StatefulSet 资 源 的 相关 状 
态 中 看 到 相关 Pod 资 源 的 就 绪 信 息 : 





~]$ kubectl1 get statefulsets myapp 





NAME DESIRED CURRENT AGE 
myapp 2 2 10m 
大 上 述 资源 的 相关 信息 一 切 正 常 ， 则 StatefulSet 资 源 myapp 已 然 整 


绪 ， 其 服务 也 可 由 其 他 依赖 方 所 调用 。 


9.2.2 ”Pod 资 源 标 识 符 及 存储 卷 


由 StatefulSet 控 制 右 创建 的 Pod 资 源 拥有 固定 、 唯 一 的 标识 和 专用 存 
储 卷 ， 即 便 重 新 调度 或 终止 后 重建 ， 其 名 称 也 依然 保持 不 变 ， 且 此 前 的 
存储 卷 及 其 数据 不 会 丢失 。 


1.Pod 资 源 的 固定 标识 符 


如 前 所 述 ， 由 StatefulSet 控 制 器 创建 的 Pod 对 象 拥有 固定 且 唯 一 的 标 
识 符 ， 它 们 基于 唯一 的 索引 序号 及 相关 的 StatefulSet 对 象 的 名 称 而 生 
成 ， 格 式 为 “<statefulset name>-<ordinal index>”， 如 下 面 的 命令 结果 所 
示 的 名 称 分 别 为 myapp-0 和 myapp-1， 其 中 myapp 为 控制 
多 \ 小 : 





~]$ kubect1l get pods -1 app=myapp-pod 


NAME READY STATUS RESTARTS AGE 
myapp-0 1/1 Running 0 4m 
myapp-1 1/1 Running 0 3m 








Pod 资 源 的 主机 名 同 其 资源 名 称 ， 因 此 也 是 囊 索 引 序号 的 名 称 格 
式 ， 如 下 面 的 命令 结果 所 示 : 





~]$ for i in © 1; do kubectl] exec myapp-$i -- sh -c 'hostname'; done 
myapp-0 
myapp-1 








这 些 名 称 标识 会 由 StatefulSet 资 源 相 关 的 Headless Service 资 源 创建 
为 DNS 资 源 记 录 ， 其 域名 格式 为 $ (service_name) .$ 
(namespace ) .svc.cluster.local， 其 中 “cluster.local* 是 集群 的 默认 域名 。 
在 Pod 资 源 创建 后 ， 与 其 相关 的 DNS 资 源 记录 格式 为 “$ (pod_name) .$ 
(service_name) .$ (namespace) .svc.cluster.local”*”， 例 如 前 面 创 建 的 两 
个 Pod 资 源 的 资源 记录 为 myapp-0. 


myapp-svc.default.svc.cluster.local 和 myapp-1.myapp- 
svc.default.svc.cluster.local。 下 面 再 创建 一 个 临时 的 Pod 资 源 ， 并 通过 其 
交互 式 接口 测试 上 述 两 个 名 称 的 解析 ， 其 中 粗 体 部 分 标识 的 内 容 为 要 运 


行 的 测试 命令 : 





~]$ kubectl run -it --image busybox dns-client --restart=Never --rm /bin/sh 
If you don't see a command prompt, try pressing enter. 

/ # nslookup myapp-0.myapp-svc 

Server: 10.96.0.10 

Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.1local 


Name: myapp-0.myapp-Svc 

Address 1: 10.244.1.25 myapp-0.myapp-Svc,default.svc,cluster. Local 
/ # nslookup myapp-1.myapp-svc 

Server: 10.96.0.10 

Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.1local 


Name: myapp-1.myapp-Svc 

Address 1: 10.244.2.23 myapp-1.myapp-svc.default.svc.cluster.1local 
/ # nslookup myapp-svc 

Server: 10.96.0.10 

Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.1local 


Name: myapp-svc 

Address 1: 10.244.1.25 myapp-0.myapp-svc.default.svc,.cluster.1local 
Address 2: 10.244.2.23 myapp-1.myapp-svc.default.svc.cluster.local 
/ # 











Headless Service 资 源 借助 于 SRV 记 录 来 引用 真正 提供 服务 的 后 端 
Pod 资 源 的 主机 名 称 ， 进 行 指向 包含 Pod IP 地 址 的 记录 条 目 。 此 外 ， 由 
StatefulSet 控 制 器 管控 的 Pod 资 源 终止 后 会 由 控制 器 自动 进行 重建 ， 虽 然 
其 IP 地 址 存在 变化 的 可 能 性 ， 但 它 的 名 称 标识 在 重建 后 会 保持 不 变 。 例 
如 ， 在 另 一 个 终端 中 删除 Pod 资 源 myapp-1: 





~]$ kubect1l delete pods myapp-1 
pod "myapp-1" deleted 





删除 完成 后 控制 器 将 随 之 开始 重建 Pod 资 源 ， 由 下 面 的 命令 结果 可 
知 ， 其 名 称 标 识 符 的 确 未 发 生 改 变 : 





~]$ kubect1l get pods -1 app=myapp-pod 


NAME READY STATUS RESTARTS AGE 
myapp-0 1/1 Running 0 8m 
myapp-1 0/1 ContainerCreating 0 0S 





Pod 资 源 重 建 完成 后 ， 再 次 由 此 前 创建 的 交互 式 测 试 终端 尝试 进行 
名 称 解 析 测 试 。 由 下 面 的 命令 结果 可 知 ，Pod 资 源 的 DNS 标 识 亦 未 发 生 
改变 ， 但 其 IP 地 址 会 指 疝 重 建 后 的 Pod 资 源 地 址 : 


有 


/ # nslookup myapp-1.myapp-svc 
Server: 10.96.0.10 
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.1local 


Name: myapp-1.myapp-Svc 
Address 1: 10.244.3.33 myapp-1.myapp-Svc,default.svc,cluster.1Local 
/# 





因此 ， 当 客户 端 尝试 向 StatefulSet 资 源 的 Pod 成 员 发 出 访问 请 求 时 ， 
应 该 针对 HeadlessService 资 源 的 CNAME (myapp- 
sVc.default.svc.cluster.local) 记录 进行 ， 它 指 癌 的 SRV 记 录 包 含 了 当前 处 
于 就 绪 状 态 的 Pod 资 源 。 当 然 ， 知 在 配置 Pod 模 板 时 定义 了 Pod 资 源 的 
liveness probe 和 readiness probe， 考 虑 到 名 称 标识 固定 不 变 ， 也 可 以 让 客 
户 端 直接 向 SRV 资 源 记 录 (myapp-0.myapp-svc 和 myapp-1.myapp-svc ) 
发 出 请 求 。 


2.Pod 资 源 的 专 有 存储 卷 
前 面 的 StatefulSet 资 源 示 例 中 ， 控 制 器 通过 volumeClaimTemplates 为 


每 个 Pod 副 本 自动 创建 并 关联 一 个 PVC 对 象 ， 它 们 分 别 绑 定 了 一 个 动态 
供给 的 PV 对 象 : 











~]$ kubectl1 get pvc -1 app=myapp-pod -ON 
custom-columns=NAME:metadata.name,VOLUME: spec.volumeName, STATUS: status.phase 
NAME VOLUME STATUS 
myappdata-myapp-0 pvc-405cf708-2ddc-11e8-b246-000c29be4e28 Bound 
myappdata-myapp-1 pvc-495f87c8-2ddc-11e8-b246-000c29be4e28 Bound 





PVC 存 储 卷 由 Pod 资 源 中 的 容器 挂 载 到 了 /usr/share/nginx/html 目 录 ， 
此 为 容器 应 用 的 Nginx 进 程 默 认 的 文档 根 路 符 。 下 面 通过 kubect] exec 命 
令 为 每 个 Pod 资 源 于 此 目录 中 生成 一 个 测试 页 面 ， 用 于 存储 卷 持 久 性 测 
试 : 








~]$ for i in 0 1; do kubect1l exec myapp-$i -- sh -c \ 
"echo $(date), Hostname: $(hostname) > /usr/share/nginx/html/index.html'; done 








接 下 来 基于 一 个 由 cirros 镜 像 启 动 的 客户 端 Pod 对 象 进 行 访问 测试 ， 
这 样 便 可 通过 其 DNS 名 称 引 用 每 个 Pod 资 源 : 





~]$ kubectl run -it --image cirros client --restart=Never --rm /bin/sh 
If you don't see a command prompt, try pressing enter. 

/ # curl myapp-0.myapp-svc 

Fri Mar 23 07:00:46 UTC 2018, Hostname: myapp-0 

/ # curl myapp-1.myapp-svc 

Fri Mar 23 07:00:46 UTC 2018, Hostname: myapp-1 

/ # 





删除 StatefulSet 控 制 器 的 Pod 资 源 ， 其 存储 卷 并 不 会 被 删除 ， 除 非 用 
户 或 管理 员 手 动 操作 移 除 操 作 。 因 此 ， 在 另 一 个 终端 省 中 删除 Pod 资 源 
myapp-0， 经 由 StatefulSet 控 制 器 重建 后 ， 它 依然 会 关联 到 此 前 的 PVC 存 
储 卷 上 ， 且 此 前 数据 依旧 可 用 : 





~]$ kubect1l delete pods myapp-0 
pod "myapp-0" deleted 





”为 一 个 终端 中 监控 到 的 删除 及 重建 过 程 如 下 面 的 命令 及 其 结果 所 
pa 





~]$ kubectl get pods -1 app=myapp-pod -w 


NAME READY STATUS RESTARTS AGE 
myapp-0 1/1 Running 0 1h 
myapp-1 1/1 Running 0 1h 
myapp-0 0/1 Terminating 0 1h 
myapp-0 0/1 Pending 0 Os 
myapp-0 0/1 Pending 0 Os 
myapp-0 0/1 ContainerCreating 0 Os 
myapp-0 1/1 Running 0 11S 





而 后 通过 测试 用 的 Pod 资 源 接口 再 次 对 其 进行 访问 测试 ， 由 如 下 内 
容 可 知 ， 存 储 卷 是 复 用 此 前 的 那个 : 





/ # curl myapp-0.myapp-svc 
Fri Mar 23 07:00:46 UTC 2018, Hostname: myapp-0 
/ # 





由 此 表明 ， 重 建 的 Pod 资 源 补 重新 调度 至 哪个 市 点， 此 前 的 PVC 资 
源 束 会 被 分 配 至 哪个 节点 ， 这 样 就 真正 实现 了 数据 的 持久 化 。 


9.3 StatefulSet 资 源 扩 缩 容 


StatefulSet 资 源 的 扩 缩 容 与 Deployment 资 源 相 似 ， 即 通过 修改 资源 
的 副本 数 来 改动 其 目标 Pod 资 源 数量 。 对 StatefulSet 资 源 来 说 ，kubectl 
scale 和 kubectl patch 命 令 均 可 实现 此 功能 ， 也 可 以 使 用 kubectl edit 命 令 直 
人 改 其 副本 数 ， 或 者 在 修改 配置 文件 之 后 ， 由 kubectlapply 命 令 重 新 声 
明 。 


例如 ， 下 面 的 命令 即 能 将 myapp 中 的 Pod 副 本 数量 扩展 至 6 个 : 











~]$ kubectl1 scale statefulset myapp --replicas=6 
statefulset.apps "myapp" scaled 





StatefulSet 资 源 的 扩展 过 程 与 创建 过 程 的 Pod 资 源 生成 全 略 相 同 ， 默 
认为 顺 次 进行 ， 而 且 其 名 称 中 的 序号 也 将 以 现 有 Pod 资 源 的 最 后 一 个 订 
号 癌 后 进行 : 








~]$ kubectl get pods -1 app=myapp-pod -w 
TUS 


NAME READY STA RESTARTS AGE 
myapp-0 1/1 Running 0 5m 
myapp-1 1/1 Running 0 4m 
myapp-2 0/1 ContainerCreating 0 10S 
myapp-2 1/1 Running 0 25S 

0 10s 


myapp-3 0/1 ContainerCreating 





与 扩容 操作 相对 ， 执 行 缩 容 操作 只 需要 将 其 副本 数量 调 低 即 可 ， 例 
如 ， 这 里 可 使 用 kubectl patch 命 令 将 StatefulSet 资 源 myapp 的 副本 数量 修 
补 为 3 个 : 





~]$ kubect1 patch statefulset myapp -p '{"spec":{"replicas":3}}'" 
statefulset.apps "myapp" patched 





纵 减 规模 时 终止 Pod 资 源 的 默认 人 策略 也 以 Pod 顺 序号 逆序 逐一 进行 ， 
直到 余下 的 数量 满足 目标 为 止 : 





~]$ kubectl get pods -1 app=myapp-pod -w 


NAME READY STATUS RESTARTS AGE 


myapp-0 1/1 Running 0 7m 
myapp-1 1/1 Running 0 6m 
myapp-2 1/1 Running 0 2m 
myapp-3 1/1 Running 0 2m 
myapp-4 1/1 Running 0 1m 
myapp-5 1/1 Running 0 1m 
myapp-5 1/1 Terminating 0 1m 
myapp-5 0/1 Terminating 0 1m 
myapp-4 1/1 Terminating 0 2m 
myapp-4 0/1 Terminating 0 2m 
myapp-3 1/1 Terminating 0 2m 
myapp-3 0/1 Terminating 0 2m 





另外 ， 终 止 Pod 资 源 后 ， 其 存储 卷 并 不 会 家 删除 ， 因 此 缩减 规模 后 
人 那么 此 前 的 数据 依然 可 用 ， 且 Pod 资 源 名 称 保持 不 


9.4 StatefulSet 资 源 升 级 


自 Kubernetes 1.7 版 本 起 ，StatefulSet 资 源 支持 自动 更 新 机 制 ， 其 更 
新 策略 将 由 spec.updateStrategy 字 段 定 义 ， 默 认为 RollingUpdate， 即 深 动 
更 新 。 男 一 个 可 用 策略 为 OnDelete， 


即 删除 Pod 资 源 重 建 以 完成 更 新 ， 这 也 是 Kubernetes 1.6 及 之 前 版 本 
唯一 可 用 的 更 新 策略 。StatefulSet 资 源 的 更 新 机 制 可 用 于 更 新 Pod 资 源 中 
的 容器 镜像 、 标 签 、 注 解 和 系统 资源 配额 等 。 


9.4.1 滚动 更 新 


滚动 更 新 StatefulSet 控 制 右 的 Pod 资 源 以 逆序 的 形式 从 其 最 大 索引 纺 
号 的 Pod 资 源 逐 一 进行 ， 它 在 终止 一 个 Pod 资 源 、 更 新 资源 并 符 其 就 绪 后 
局 动 更 新 下 一 个 资源 ， 即 索引 号 比 当前 号 小 1 的 Pod 资 源 。 对 于 主 从 复制 
类 的 集群 应 用 来 说 ， 这 样 也 能 保证 起 主 市 点 作用 的 Pod 资 源 最 后 进行 更 
新 ， 人 确保 兼容 性 。 


StatefulSet 的 默认 更 新 集 略 为 深 动 更 新 ， 通 过 “kubectl] get statefulset 
NAME” 命 令 中 的 输出 可 以 获取 相关 的 信息 ，myapp 控 制 副 的 输出 如 下 所 
人 : 





updateStrategy : 
rollingUpdate: 
partition: 0 
type: RollingUpdate 





更 新 Pod 中 的 容器 镜像 可 以 使 用 “kubectl set image” 命 令 进 行 ， 例 如 
下 面 的 命令 可 将 myapp 控 制 器 下 的 Pod 资 源 镜 像 版 本 升级 
为 “ikubernetes/myapp: v6”: 





~]$ kubect1 set image statefulset myapp myapp=ikubernetes/myapp:v6 
statefulset.apps "myapp" image updated 





更 新 操作 过 程 ， 可 在 另 一 终端 中 使 用 如 下 命令 进行 监控 ， 其 逆序 操 
作 Pod 资 源 的 过 程 如 下 面 的 命令 结果 所 示 : 





~]$ kubectl get pods -1 app=myapp-pod -w 

NAME READY STATUS RESTARTS AGE 
myapp-0 1/1 Running 0 11m 
myapp-1 1/1 Running 0 11m 
myapp-2 1/1 Running 0 6m 
myapp-2 1/1 Terminating 0 7m 
myapp-2 0/1 Terminating 0 7m 
myapp-2 0/1 Pending 0 Os 
myapp-2 0/1 ContainerCreating 0 Os 
myapp-2 1/1 Running 0 11S 
myapp-1 1/1 Terminating 0 11m 
myapp-1 0/1 Terminating 0 11m 
myapp-1 0/1 Pending 0 Os 


myapp-1 
myapp-1 
myapp-0 
myapp-0 
myapp-0 
myapp-0 
myapp-0 





等 更 新 完成 后 ， 获 取 每 个 Pod 资 源 中 的 镜像 文件 版 本 即 可 验证 其 升 


级 结果 : 





~]$ for i in 0 1 2; do kubect] get po myapp-$i \ 
--template '{{range $i, $c 
ikubernetes/myapp:v6 
ikubernetes/myapp:v6 
ikubernetes/myapp:v6 





另外 ， 用 户 也 可 以 使 用 “kubectl rollout status” 命 令 跟 踪 StatefulSet 资 


0/1 
1/1 
1/1 
0/1 
0/1 
0/1 
1/1 


ContainerCreating 
Running 
Terminating 
Terminating 
Pending 
ContainerCreating 
Running 


源深 动 更 新 过 程 中 的 状态 信息 。 


OOOOOOO 


2S 
18s 
12m 
12m 
Os 
Os 
1is 


:= .Spec.containers}}{{$c.image}}{{end}}'; echo; done 


9.4.2 ”上 暂 存 更 新 操作 


当 用 户 需 要 设 定 一 个 更 新 操作 ， 但 又 不 希望 它 立 即 执行 时 ， 可 将 更 
新 操作 予以“ 暂 存 ”"， 待 条 件 满足 后 再 手动 触发 其 执行 更 新 。StatefulSet 
资源 的 分 区 更 新 机 制 能 够 实现 此 项 功 能 。 在 设 定 更 新 操作 之 前 ， 
将 .spec.update-Strategy.rollingUpdate.partition 字 段 的 值 设 置 为 Pod 资 源 的 
副本 数量 ， 即 比 Pod 资 源 的 最 大 索引 号 大 1， 这 就 意味 痢 ， 所 有 的 Pod 资 
源 都 不 会 处 于 可 直接 更 新 的 分 区 之 内 〈 如 图 9-4 所 示 ) ， 那 么 于 其 后 设 
定 的 更 新 操作 也 就 不 会 真正 执行 ， 直 到 用 户 降 低 分 区 编号 至 现 有 Pod 资 


源 索 引号 范围 之 内 。 


图 9-4 和 暂 存 更 新 


下 面 测试 深 动 更 新 的 暂 存 更 新 操作 ， 首 先 将 StatefulSet 资 源 myapp 的 
深 动 更 新 分 区 值 设 定 为 3: 



















StatefulSet myapp 
replicas: 3 


Pod 
myapp:v6 














partition=3 


一 4 一 一 








~]$ kubectl patch statefulset myapp \ 
-p '{"spec":{"updateSstrategy":{"rollingUpdate":{"partition":3}}}}" 
statefulset.apps "myapp" patched 





而 后 ， 将 myapp 控 制 器 的 Pod 资 源 镜像 版 本 更 新 
为 “ikubernetes/myapp: V7”: 





~]$ kubect1 set image statefulset myapp myapp=ikubernetes/myapp:v7 
statefulset.apps "myapp" image updated 





本 可 以 发 现 其 版 本 并 未 发 





$ kubect1 get pods -1 app=myapp-pod \ 
-0 Custom-columns=NAME:metadata.name, IMAGE: spec.containers[0].image 
NAME IMAGE 
myapp-0 ikubernetes/myapp:v6 
myapp-1 ikubernetes/myapp:v6 
myapp-2 ikubernetes/myapp:v6 





此 时 ， 即 便 删 除 芭 Pod 资 源 ， 它 依然 会 基于 旧 的 版 本 镜像 进行 重 
建 。 例 如 ， 下 面 首 移 删除 了 Pod 对 象 myapp-1， 随 后 待 其 重建 操作 局 动 
后 ， 再 获取 与 其 相关 的 镜像 信息 ， 结 果 依 然 显 示 了 旧 的 版 本 : 





~]$ kubect1l delete pods myapp-1 
pod "myapp-1" deleted 
~]$ kubectl get pods myapp-1 \ 
-0 cusStom-columns=NAME:metadata.name, IMAGE: spec.containers[0].image 
NAME IMAGE 
myapp-1 ikubernetes/myapp:v6 








由 此 可 见 ， 暂 存 状态 的 更 新 操作 对 所 有 的 Pod 资 源 均 不 产生 影响 。 


9 全 纪念 部 阁 


将 处 于 暂 存 状态 的 更 新 操作 的 partition 定 位 于 Pod 资 源 的 最 大 索引 
写 ， 即 可 放出 一 只 金 丝 汗 ， 由 其 测试 第 一 轮 的 更 新 操作 ， 在 确认 无 误 后 


将 9.4.2 节 暂停 的 更 新 StatefulSet 控 制 器 myapp 资 源 的 分 区 号 设置 为 
Pod 资 源 的 最 大 索引 号 2， 将 会 触发 myapp-2 的 更 新 操作 : 





~]$ kubect1 patch statefulset myapp -p '{"spec":{"updatestrategy":{"rollingUpdate":1 
statefulset.apps "myapp" patched 





其 执行 结果 如 图 9-5 所 示 。 





StatefulSet myapp 










Pod myapp-0 


es partition=2 


replicas: 3 


Pod 
myapp:v6 





图 9-5 ” 金 丝 淮 发 布 


待 其 更 新 完成 后 ， 检 测 所 有 Pod 资 源 使 用 的 镜像 文件 版 本 ， 对 比 下 
5 可 以 看 出 其 更 新 操作 再 次 暂停 于 myapp-2 的 更 新 操作 完 
之 后 : 





~]$ kubectl get pods -1 app=myapp-pod \ 

-0 cusStom-columns=NAME:metadata.name, IMAGE: spec.containers[0].image 
NAME IMAGE 
myapp-0 ikubernetes/myapp:v6 


myapp-1 ikubernetes/myapp:v6 
myapp-2 ikubernetes/myapp:v7 





此 时 ， 位 于 非 更 新 分 区 内 的 其 他 Pod 资 源 仍 不 会 被 更 新 到 新 的 镜像 
版 本 ， 哪 怕 它 们 被 删除 后 重建 亦 是 如 此 。 


9.4.4 ”分 段 更 新 


金 丝 人 省 安然 度 过 测试 阶段 之 后 ， 用 户 便 可 局 动 后 续 其 他 Pod 资 源 的 

更 新 操作 。 在 待 更 新 的 Pod 资 源 数量 较 少 的 情况 下 ， 直 接 将 partition 属 性 
的 值 设 置 为 0， 它 将 逆序 完成 后 续 所 有 Pod 资 源 的 更 新 。 而 当 符 更 新 的 
Pod 资 源 较 多 时 ， 用 户 也 可 以 将 Pod 资 源 以 线性 或 指数 级 增长 的 方式 来 分 
阶段 完成 更 新 操作 ， 操 作 过 程 无 非 是 分 步 更 新 partition 属 性 值 ， 例 如 ， 
将 myapp 控 制 右 的 分 区 吕 码 依次 设置 为 1、0 以 完成 剩余 Pod 资 源 的 线性 
分 步 更 新 ， 如 图 9-6 所 示 。 

StatefulSet myapp 


he Pod myapp-0 
replicas: 3 partition=1 


Pod et ' 
myapp:v6 : 2 










partition=0 










StatefulSet myapp 
replicas: 3 


Pod 
myapp:v6 





图 9-6 分 阶段 更 新 
符 更 新 全 部 完成 后 ， 用 户 便 可 根据 需求 筹划 下 一 轮 的 更 新 操作 。 


9.4.5 ”其 他 话题 


同 其 他 类 型 的 Pod 控 制 器 资源 类 似 ，StatefulSet 也 支持 级 联 或 非 级 联 
的 删除 操作 。 默 认 的 删除 类 型 为 级 联 删 除 ， 即 同时 删除 StatefulSet 和 相 
关 的 Pod 资 源 。 知 要 执行 非 级 联 删除 ， 为 删除 命令 使 用 “-- 
cascade=false” 选 项 即 可 。 


男 外 ，StatefulSet 控 制 右 管理 Pod 资 源 的 策略 除了 默认 的 
OrderedReady《 顺 次 创建 及 逆序 删除 ) 之 外 ， 还 支持 并 行 的 创建 和 删除 
操作 ， 即 同时 创建 所 有 的 Pod 资 源 以 及 同时 删除 所 有 的 Pod 资 源 ， 完 成 这 
一 点 ， 只 需要 将 spec.podManagementPolicy 字 段 的 值 设置 为 Parallel 即 
可 ， 不 过 对 于 有 角色 之 分 的 分 布 式 应 用 来 说 ， 为 了 保证 数据 安全 可 靠 ， 
建议 使 用 默认 策略 ， 除 非 数 据 完 整 性 是 可 以 不 用 考虑 在 内 的 因素 。 


另外 ， 不 同 的 有 状态 应 用 的 运 维 操作 过 程 差 别 巨 大 ， 因 此 
StatefulSet 控 制 器 本 号 几 乎 无 法 为 此 种 类 型 的 应 用 提供 完善 的 通用 管理 
控制 机 制 ， 现 实 中 的 各 种 有 状态 应 用 通常 是 使 用 专用 的 自 定义 控制 嚣 专 
门 封装 特定 的 运 维 操作 流程 ， 这 些 自 定义 控制 器 有 时 也 被 统一 称 为 
Operator， 这 些 内 容 将 在 后 面 的 章节 介绍 。 





9.5 ”案例 : etcd 和 集群 


Kubernetes 的 所 有 对 象 都 需要 持久 化 存储 于 etcd 存 储 系统 中 ， 以 确 
保 系 统 重 启 或 故障 恢复 后 能 将 它们 予以 还 原 。 


etcd 是 一 个 分 布 式 键 值 数据 存储 系统 ， 具 有 可 靠 、 快 速 、 强 一 致 性 
等 特性 ， 它 通过 分 布 式 锁 、leader 选 举 和 写 屏 障 (write barriers) 来 实现 
可 靠 的 分 布 式 协作 。 因 此 ，Kubernetes 系 统管 理 员 应 该 将 etcd 部 署 为 集 
群 工作 模型 ， 以 实现 其 服务 高 可 用 ， 并 提供 更 好 的 性 能 表现 。 


etcd 将 键 存 储 于 层级 组 织 的 键 空间 中 ， 这 使 得 它 看 起 来 非常 类 似 于 
文件 系统 的 倒置 树 状 结构 ， 于 是 ， 它 的 每 个 键 要 么 是 一 个 包含 有 其 他 键 
的 目录 ， 要 么 是 一 个 含有 数据 的 稼 规 键 。Kubernetes 将 其 所 有 数据 存储 
于 etcd 的 /nregistry 目 录 中 ， 虽 然 API Server 是 以 JSON 格 式 组 织 数据 资源 对 
象 ， 但 对 于 底层 使 用 etcd 存 储 系统 的 场景 来 说 ， 它 们 可 类 比 为 存储 于 文 
件 系 统 内 的 JSON 文 件 中 。 另 外 ，Kubernetes 的 系统 组 件 中 ， 仅 API 
Server 和 直接 与 etcd 进 行 通信 ， 其 他 所 有 组 件 的 数据 读 写 操作 都 要 经 由 API 
Server 进 行 ， 从 而 确保 了 数据 的 高 度 一 致 性 。 


在 分 布 式 模型 中 ，etcd 采 用 raft 算 法 ， 实 现 了 分 布 式 系统 数据 的 可 用 
性 和 一 致 性 。 知 发 生 网 络 分 区 或 节点 故障 ， 则 raft 算 法 就 会 通过 quorum 
机 制 处 理 集 群 状态 转移 ， 其 中 成 员 数 量 大 于 半数 的 一 方 可 继续 工作 ， 知 
leader 存 在 ， 则 它们 可 继续 提供 读 写 服务 ， 否 则 就 要 选举 出 新 的 leader， 
并 且 在 此 期 间 写 操作 是 被 禁止 的 ， 而 成 员 数 量 少 于 半数 的 节点 将 停止 任 
何 的 写 入 操作 。 本 节 将 描述 如 何 于 Kubernetes 集 群 中 基于 StatefulSet 控 制 
器 托管 部 署 一 个 分 布 式 的 etcd 集 群 ， 它 只 是 一 个 部 署 示 例 ， 并 不 会 取代 
Kubernetes 系 统 现 有 的 etcd。 









































9.5.1 创建 Service 资 源 


StatefulSet 资 源 依 赖 于 Headless Service 为 各 Pod 资 源 提 供 名 称 解 析 服 
务 ， 其 他 Pod 资 源 可 直接 使 用 DNS 名 称 来 获取 相关 的 服务 ， 如 etcd- 
0.etcd、etcd-1.etcd 等 ， 下 面 的 资源 清单 〈etcd-services.yaml) 中 定义 的 
第 一 个 资源 etcd 就 是 此 类 的 Service 资 源 。 第 二 个 名 为 etcd-client 的 Service 
资源 是 一 个 正常 的 Service， 它 拥有 ClusterIP， 并 可 通过 NodePort 回 
Kubernetes 集 群 外 部 的 etcd 客 户 端 提供 服务 : 





apiVersion: v1 
kind: Service 
metadata: 

name: etcd 

annotations: 

# Create endpoints also if the related pod isn't ready 
service.alpha.kubernetes.io/tolerate-unready-endpoints: "true" 
spec: 

ports: 

- port: 2379 
name: client 

- port: 2380 
name: peer 

clusterIP: None 

selector: 
app: etcd-member 
apiVersion: v1 
kind: Service 
metadata: 

name: etcd-client 

spec: 

ports: 

- name: etcd-client 
port: 2379 
protocol: TCP 
targetPort: 2379 

selector: 
app: etcd-member 

type: NodePort 





首先 创建 上 述 两 个 Service 对 象 : 





~]$ kubectl1 apply -f etcd-services.yaml 
service "etcd-svc" created 
service "etcd-client" created 





而 后 ， 可 于 default 名 称 空 间 中 看 到 如 下 两 个 Service 资 源 记 录 : 





~]$ kubectl1 get svc -1 app=etcd 


NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
etcd ClusterIP None <none> 2379/TCP, 2380/TCP 5S 
etcd-client NodePort 10.244.60.53 <none> 2379:30290/TCP 5s 





由 上 面 输出 的 信息 可 以 看 出 ，etcd-client 通 过 10.99.175.53 向 客户 端 
提供 服务 ， 它 是 一 个 标准 类 型 的 Service 资 源 ， 类 型 为 NodePort， 可 通过 
各 工作 节点 的 30290 端 口 将 服务 暴露 到 集群 外 部 。 服 务 类 型 的 资源 创建 
完成 后 ， 接 下 来 便 可 创建 StatefulSet 控 制 器 ， 构 建 分 布 式 etcd 集 群 。 


9.5.2 etcd StatefulSet 


etcd 依 赖 于 持久 存储 设备 保存 数据 ， 这 里 为 其 配置 了 使 用 自 定 义 
的 、 具 有 动态 PV 供给 功能 的 gluster-dynamic 存 储 类 为 各 Pod 资 源 的 PVC 
提供 存储 后 端 ， 大 小 可 由 用 户 按 需求 进行 定义 。 男 外 ，etcd 镜 像 文件 的 
版 本 也 可 由 用 户 修 改 为 与 实际 需求 匹配 的 版 本 ， 如 3.3.1 等 ， 不 过 
StatefulSet 本 就 文 持 自动 更 新 机 制 ， 用 户 也 可 以 于 必要 时 局 动 更 新 机 制 
切换 其 镜像 版 本 。 下 面 是 定义 在 etcd-statefulset.yaml 文 件 中 的 配置 示 
例 ， 它 定义 了 一 个 名 为 etcd 的 StatefulSet 资 源 : 











apiVersion: apps/v1 
kind: StatefulSet 
metadata: 
name: etcd 
lJabels: 
app: etcd 
spec: 
serviceName: etcd 
# changing replicas value will require a manual etcdct] member remove/add 
# command (remove before decreasing and add after increasing) 
replicas: 3 
selector: 
matchLabels: 
app: etcd-member 
template: 
metadata: 
name: etcd 
lJabels: 
app: etcd-member 
spec: 
containers: 
- name: etcd 
image: "quay.io/coreos/etcd:v3.2.16" 
ports: 
- containerPort: 2379 
name: client 
- containerPort: 2380 
name: peer 
env: 
- Name: CLUSTER_SIZE 
value: "3" 
- Name: SET_NAME 
value: "etcd" 
VOLumeMounts : 
- name: data 
mountPath: /var/run/etcd 
command : 
- "/bin/sh" 
是 0-eCxn 


< | 
IP=$(hostname -i) 


PEERS="" 
for i in $(seq © $((${CLUSTER_SIZE} - 1))); do 
PEERS="${PEERS}${PEERS:+, }${SET_NAME}-${i}=http://${SET_NAME}- 
${i}.${SET_NAME}:2380" 
done 
# Start etcd. If cluster is already initialized the “--Initial-* 
options will be ignored. 
exec etcd --name ${HOSTNAME} \ 
--listen-peer-urls http://${IP}:2380 \ 
--listen-client-urls http://${IP}:2379,http://127.0.0.1:2379 \ 
--advertise-client-urls http://${HOSTNAME}.${SET_ NAME}:2379 \ 
--initial-advertise-peer-urls http://${HOSTNAME}.${SET_ NAME}:2380 \ 
--initial-cluster-token etcd-cluster-1 \ 
--initial-cluster ${PEERS} \ 
--initial-cluster-state new \ 
--data-dir /var/run/etcd/default.etcd 
volumeClaimTemplates: 
- metadata: 
name: data 
spec: 
storageClassName: gluster-dynamic 
accessModes: 
- "ReadwriteOnce" 
resources: 
requests: 
storage: 16i 





首先 ， 将 上 述 资 源 定义 创建 于 集群 中 。 当 依 赖 肌 错 像 浆 件 个 存在 
时 ， 下 载 镜像 的 过 程 会 导致 创建 时 长 略 长 ， 此 处 需要 耐心 等 街 





~]$ kubect1l apply -f etcd-statefulset.yaml 
statefulset.apps "etcd" created 





在 男 一 终端 ， 可 使 用 下 列 命 令 监 控 各 Pod 资 源 的 创建 过 程 ， 直 到 它 
们 都 转 为 正常 的 运行 状态 为 止 : 





~]$ kubect1 get pods -1 app=etcd-member -w 


NAME READY STATUS RESTARTS AGE 
etcd-0 0/1 Pending 0 Os 
etcd-0 0/1 Pending 0 Os 
etcd-0 0/1 ContainerCreating 0 0S 
etcd-0 1/1 Running 0 11S 
etcd-1 0/1 Pending 0 Os 
etcd-1 0/1 Pending 0 Os 
etcd-1 0/1 ContainerCreating 0 0S 
etcd-1 1/1 Running 0 11S 
etcd-2 0/1 Pending 0 Os 
etcd-2 0/1 Pending 0 Os 
etcd-2 0/1 ContainerCreating 0 1S 
etcd-2 1/1 Running 0 15S 


mr | 


而 后 ， 检 测 9.5.1 节 中 创建 的 Service 资 源 etcd-svc 和 etcd-client 是 否 已 
经 正常 关联 到 相关 的 Pod 资 源 。 下 面 的 命令 结果 表示 它们 都 已 经 通过 标 
签 选 择 絮 关联 到 了 由 Pod 资 源 生 成 的 Endpoints 资 源 之 上 ， 这 些 Pod 资 源 是 
由 StatefulSet 控 制 器 etcd 创 建 而 成 的 : 





~]$ kubectl get endpoints -1 app=etcd 


NAME ENDPOINTS AGE 
etcd 10.244.1.50:2380,10.244.2.50:2380,10.244.3.57:2380 + 3 more... 1m 
etcd-client 10.244.1.50:2379,10.244.2.50:2379,10.244.3.57:2379 1m 





对 比 由 etcd 控 制 占 创 建 的 Pod 资 源 的 相关 信息 可 知 ， 上 面 的 
Endpoints 中 的 IP 地 址 均 属 于 由 etcd 控 制 创建 的 Pod 资 源 : 





~]$ kubectl1 get pods -1 app=etcd-member -0 wide 


NAME READY STATUS RESTARTS AGE IP NODE 

etcd-0 1/1 Running 0 1m 10.244.3.57 node03.ilinux.io 
etcd-1 1/1 Running 0 1m 10.244.1.50 node01.ilinux.io 
etcd-2 1/1 Running 0 1m 10.244.2.50 node02.ilinux.io 





使 用 etcd 的 客户 端 工 具 etcdctl 检 测 集 群 的 健康 状态 : 





~]$ kubectl1 exec etcd-0 -- etcdct1 cluster-health 

member 2e80f96756a54ca9 is healthy: got healthy result from http://etcd-0.etcd:2379 
member 7fd61f3f79d97779 is healthy: got healthy result from http://etcd-1.etcd:2379 
member b429c86e3cd4e077 is healthy: got healthy result from http://etcd-2.etcd:2379 
cluster is healthy 








至 此 ， 一 个 由 三 节点 (Pod 资源 ) 组 成 的 etcd 和 集群 已 经 正常 运行 起 
来 了 ， 客 户 端 可 从 各 工作 节点 的 30290 端 口 在 Kubernetes 集 群 外 部 进行 访 
问 ， 而 各 Pod 资 源 既 可 以 直接 癌 Service 资 源 etcd-client 的 名 称 或 
10.106.60.53 〈ClusterIP) 发 出 访问 请 求 ， 也 可 以 向 Headless Service 资 源 
的 名 称 etcd 进 行 请 求 。 


需要 注意 的 是 ， 前 面 的 配置 文件 中 提供 的 Statefulset 资 源 配置 要 求 
进行 规模 变动 时 ， 需 要 手动 对 etcd 集 群 执行 命令 以 完成 节点 的 添加 或 其 
除 ， 而 且 缩 容 时 要 先 移 除 节点 再 缩减 副本 数量 ， 扩 容 时 要 先 提升 副本 数 
量 再 添加 节点 ， 因 此 它 的 主要 目标 里 不 包含 应 用 规模 的 自由 变动 ， 但 对 
于 应 用 升级 的 支持 完好 。 例 如 ， 将 镜像 文件 版 本 升级 至 v3.2.17 的 版 本 ; 














~]$ kubect1 set image statefulset etcd etcd=quay.io/coreos/etcd:v3.2.17 
statefulset.apps "etcd" image updated 





而 后 使 用 “kubectl rollout status” 命 令 监 控 其 深 动 升级 过 程 中 的 状态 
变动 : 





~]$ kubect1l rollout status statefulset etcd 

Waiting for 1 pods to be ready... 

Waiting for partitioned roll out to finish: 1 out of 3 new pods have been updated.., 
Waiting for 1 pods to be ready... 

Waiting for partitioned roll out to finish: 2 out of 3 new pods have been updated.., 
Waiting for 1 pods to be ready... 

partitioned roll out complete: 3 new pods have been updated... 





升级 完成 后 ， 可 于 相关 的 任 一 Pod 资 源 中 运行 etcdet 命 令 合 看 应 用 
程序 的 版 本 是 否 已 经 升级 完成 : 








~]$ kubect1 exec etcd-0 -- etcdct1 -v 
etcdct1 version: 3.2.17 
API version: 2 





由 上 面 命 令 结果 可 见 ， 应 用 程序 已 经 成 功 升级 至 3.2.17 的 版 本 。 滚 
动 升级 过 程 中 ， 处 于 更 新 过 程 的 Pod 资 源 对 象 无 法 正常 使 用 ， 不 过 ， 客 
户 端 是 通过 Service 资 源 提供 的 入 口 而 非 Pod 资 源 本 身 的 标识 〈 如 名 称 或 
了 地 址 ) 来 进行 访问 ， 因 此 并 不 会 出 现 服 务 不 可 用 问题 。 





9.6 ”本章 小 结 

本 章 着 重 讲解 了 有 状态 应 用 的 Pod 资 源 控制 器 Statefulset， 有 状态 应 
用 相 较 于 无 状态 应 用 来 说 ， 在 管理 上 有 着 特有 的 复杂 之 处 ， 甚 至 不 同 的 
有 状态 应 用 的 管理 方式 各 不 相同 ， 在 部 署 时 需要 予以 精心 组 织 。 


.StatefulSet 依 赖 于 Headless Service 资 源 为 其 Pod 资 源 创 建 DNS 资 源 记 
孙 。 


-每 个 Pod 资 源 均 拥有 固定 且 唯 一 的 名 称 ， 并 且 需 要 由 DNS 服务 解 
订 。 


-Pod 资 源 中 的 应 用 需要 依赖 于 PVC 和 PV 持 久保 存 其 状态 数据 。 
文 持 扩 容 和 缩 容 ， 但 具体 的 实现 机 制 依赖 于 应 用 本 刁 。 
文 持 上 自动 更 新 ， 默 认 的 更 新 全 略为 滚动 更 新 机 制 。 








第 10 革 认证、 授权 与 准 入 控制 


在 任何 将 资源 或 服务 提供 给 有 限 使 用 者 的 系统 上 ， 认 证 和 授权 都 是 
两 个 必 不 可 少 的 功能 ， 认 证 用 于 和 里 份 鉴别 ， 而 授权 则 实现 权限 分 派 。 
Kubernetes 以 插件 化 的 方式 实现 了 这 两 种 功能 ， 且 分 别 存在 多 种 可 用 的 
插件 。 男 外 ， 它 还 支持 准 入 控制 机 制 ， 用 于 补充 授权 机 制 以 实现 更 精细 
i 本 半 主 要 讲解 Kubernetes 系 统 和 常用 的 认证 、 授 权 及 准 

空 制 机 制 |。 





10.1 访问 控制 概述 


API Server 作 为 Kubernetes 集 群 系统 的 网 天 ， 是 访问 及 管理 资源 对 象 
的 唯一 入 口 ， 余 下 所 有 需要 访问 集群 资源 的 组 件 ， 包 括 kube-controller- 
manager、kube-scheduler、kubelet 和 kube-proxy 等 集群 基础 组 件 、 
CoreDNS 等 集群 的 附加 组 件 以 及 此 前 使 用 的 kubect 命 令 等 都 要 经 由 此 网 
关 进 行 集群 访问 和 管理 。 这 些 客户 端 均 要 经 由 API Server 访 问 或 改变 集 
群 状态 并 完成 数据 存储 ， 并 由 它 对 每 一 次 的 访问 请 求 进行 合法 性 检验 ， 
包括 用 户 身 份 鉴别 、 操 作 权 限 验 证 以 及 操作 是 否 符 合 全 局 规范 的 约束 
等 。 所 有 检查 均 正 常 完成 且 对 象 配置 信息 合法 性 检验 无 误 之 后 才能 访问 
或 存 入 数据 于 后 端 存储 系统 etcd 中 ， 如 图 10-1 所 示 。 


客户 端 认证 操作 由 API Server 配 置 的 一 到 多 个 认证 插件 完成 。 收 到 
请 求 后 ，API Server 依 次 调用 为 其 配置 的 认证 插件 来 认证 客户 端 身 份 ， 
直到 其 中 一 个 插件 可 以 识别 出 请 求 者 的 号 份 为 止 。 授 权 操 作 由 一 到 多 个 
授权 插件 进行 ， 它 负责 确定 那些 通过 认证 的 用 户 是 否 有 权限 执行 其 发 出 
的 资源 操作 请 求 ， 如 创建 、 读 取 、 删 除 或 修改 指定 的 对 象 等 。 随 后 ， 通 
过 授权 检测 的 用 户 所 请 求 的 修改 相关 的 操作 还 要 经 由 一 到 多 个 准 入 控制 
插件 的 过 历 检测 ， 例 如 使 用 默认 值 补足 要 创建 的 目标 资源 对 象 中 未 定义 
的 各 字段 、 检 查 目 标 Namespace 资 源 对 象 是 否 存 在 、 检 查 是 否 违 反 系统 
资源 限制 ， 等 等 ， 而 其 中 任何 的 检查 失败 都 可 能 会 导致 号 入 操作 失败 。 
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图 10-1 用 户 账号 、 服 务 账号 、 认 证 、 授 权 和 准 入 控制 


11 用 性 账 户 与 用 户 租 


Kubernetes 并 不 会 存储 由 认证 插件 从 客户 端 请 求 中 提取 出 的 用 户 及 
所 属 组 的 信息 ， 它 们 仅仅 用 于 检验 用 户 是 否 有 权限 执行 其 所 请 求 的 操 
作 。 客 户 端 访问 API 服 务 的 途径 通常 有 三 种 : kubectl、 客 户 端 库 或 者 直 
接 使 用 REST 接 口 进行 请 求 ， 而 可 以 执行 此 类 请 求 的 主体 也 被 Kubernetes 
分 为 两 类 : 现实 中 的 “< 人 ”和 Pod 对 象 ， 它 们 的 用 户 身 份 分 别 对 应 于 常规 
用 户 (User Account) 和 服务 账号 (Service Account) 。 











User Account 《用户 账 号 ) : 一 般 是 指 由 独立 于 Kubernetes 之 外 的 
其 他 服务 管理 的 用 户 账 号 ， 例 如 由 管理 员 分 发 的 密 钥 、Keystone 一 类 的 
用 户 存 储 〈( 账 号 库 ) 、 甚 至 是 包含 有 用 户 名 和 密码 列表 的 文件 等 。 
Kubernetes 中 不 存在 表示 此 类 用 户 账 号 的 对 象 ， 因 此 不 能 被 直接 添加 进 
Kubernetes 系 统 中 。 





.Service Account (服务 账号 ) : 是 指 由 Kubernetes API 管 理 的 账 
号 ， 用 于 为 Pod 之 中 的 服务 进程 在 访问 Kubemetes API 时 提供 身份 标识 
Cidentity) 。Service Account 通 常 要 绑 定 于 特定 的 名 称 空间 ， 它 们 由 
API Server 创 建 ， 或 者 通过 API 调 用 手动 创建 ， 附 融 着 一 组 存储 为 Secret 
的 用 于 访问 API Server 的 凭据 。 


User Account 通 常用 于 复杂 的 业务 逻辑 管控 ， 它 作用 于 系统 全 局 ， 
故 其 名 称 必须 全 局 唯一 。 相 比较 来 说 ，Service Account 隶 属于 名 称 空 
间 ， 仪 用 于 实现 某 些 特定 的 操作 任务 ， 因 此 要 轻 量 得 多 。 这 两 类 账号 都 
可 以 隶属 于 一 个 或 多 个 用 户 组 。 用 户 组 只 是 用 户 账 号 的 逻辑 集合 ， 它 本 
身 并 没有 操作 权限 ， 但 附加 于 组 上 的 权限 可 由 其 内 部 的 所 有 用 户 继承 ， 
人 Kubernetes 有 着 以 下 几 个 内 建 的 用 于 特殊 
目的 的 组 。 


system: unauthenticated: 未 能 通过 任何 一 个 授权 插件 检验 的 账 
写 ， 即 未 通过 认证 测试 的 用 户 所 属 的 组 。 


“system: authenticated: 认证 成 功 后 的 用 户 自 动 加 入 的 一 个 组 ， 用 
于 快捷 引用 所 有 正常 通过 认证 的 用 户 账号 。 


.System: serviceaccounts: 当前 系统 上 的 所 有 Service Account 对 象 。 











.System: serviceaccounts: <namespace>: 特定 名 称 空间 内 所 有 的 
Service Account 对 象 。 


API 请 求 要 么 与 普通 用 户 或 服务 账户 进行 绑 定 ， 要 么 被 视 为 匿名 请 
求 。 这 意味 着 群集 内 部 或 外 部 的 每 个 进程 ， 包 括 由 人 类 用 户 使 用 的 
kubectl， 到 节点 上 的 kubelet， 再 到 控制 平面 的 成 员 组 件 ， 必 须 在 向 API 
服务 器 发 出 请 求 时 进行 身份 验证 ， 人 否则 即 被 视 为 匿名 用 户 。 





10.1.2 认证、 授权 与 准 入 控制 基础 


API Server 处 理 请 求 的 过 程 中 ， 认 证 插件 负责 鉴定 用 户 身 份 ， 授 权 
插件 用 于 操作 权限 许可 鉴别 ， 而 准 入 控制 则 用 于 在 资源 对 象 的 创建 、 删 
除 、 更 新 或 连接 (proxy) 操作 时 实现 更 精细 的 许可 检查 ， 其 相互 间 的 
作用 关系 如 图 10-1 所 示 。 


Kubernetes 使 用 身份 验证 插件 对 API 请 求 进行 身份 验证 ， 支 持 的 认证 
方式 包括 客户 问 证 书 、 承 载 令 脾 (bearer tokens) 、 喘 份 验证 代理 
(authenticating proxy) 或 HITP basic 认 证 等 。API Server 接 收 到 访问 请 
求 时 ， 它 将 调用 认证 插件 尝试 将 以 下 属性 与 访问 请 求 相关 联 。 
“Username: 用 户 名 ， 如 kubernetes-admin 等 。 
UID: 用户 的 数字 标签 符 ， 用 于 确保 用 户 喘 份 的 唯一 性 。 
.Groups: 用 户 所 属 的 组 ， 用 于 权限 指派 和 继承 。 


Extra: 键 值 数据 类 型 的 字符 串 ， 用 于 提供 认证 时 需要 用 到 的 额外 











API Server 文 持 同 时 局 用 多 种 认证 机 制 ， 但 至 少 应 该 分 别 为 Service 
Account 和 User Account 各 上 自 启用 一 个 认证 插件 。 同 时 启用 多 种 认证 机 制 
时 ， 认 证 过 程 会 以 串 行 的 方式 进行 ， 直 到 一 种 认证 机 制 成 功 完成 即 结 
束 。 若 认证 失败 ， 则 服务 器 会 啊 应 401 状 态 码 ， 反 之 ， 请 求 者 就 会 被 识 
别 为 某 个 具体 的 用 户 〈 以 其 用 户 名 进行 标识 ) ， 并 且 随 后 的 操作 都 将 以 
此 用 户 身 份 来 进行 。 


具体 来 说 ，API Server 文 持 以 下 几 种 具体 的 认证 方式 ， 其 中 所 有 的 
令 牌 认证 机 制 通常 被 统称 为 承载 令 牌 认证 。 


1) X509 客 户 端 证 书 认 证 : 客户 端 在 请 求 报 文 中 携带 X509 格 式 的 数 
字 证 书 用 于 认证 ， 认 证 通过 后 ， 证 书 中 的 主体 标识 (Subject) 将 被 识别 
为 用 户 标 识 ， 其 中 的 CN (‘Common Name) 字段 是 用 户 名 ， 
O (Organization〉 是 用 户 所 属 的 组 ， 
如 “/CN=ilinux/O=opmasters/O=admin” 中 ， 用 户 名 为 ilinux， 其 属于 








opmasters 和 admin 两 个 组 。 


2) 静态 令 牌 文件 (Static Token File) : 即 保存 着 令 牌 信息 的 文 
件 ， 由 kube-apiserver 的 命令 行 选项 --token-auth-file 加 载 ， 且 服务 器 局 动 
后 不 可 更 改 ;HTTP 客户 端 也 能 使 用 承载 令 牌 进行 身份 验证 ， 将 令 牌 进 
行 编码 后 ， 通 过 请 求 报 文中 的 Authorization 首 部 承载 传递 给 API Server 即 
向 | 


3) 引导 令 牌 (Bootstrap Tokens) : 一 种 动态 管理 承载 令 牌 进行 身 
份 认证 的 方式 ， 常 用 于 简化 新 建 Kubernetes 集 群 的 节点 认证 过 程 ， 需 要 
通过 --experimental-bootstrap-token-auth 选 项 启用 ; 有 新 的 工作 节点 首次 
加 入 时 ，Master 使 用 引导 令 牌 确认 市 点 映 份 的 合法 性 之 后 自动 为 其 签署 
数字 证 书 以 用 于 后 续 的 安全 通信 ， 使 用 kubeadm join 命令 将 节点 加 入 
kubeadm 初 始 化 的 集群 时 使 用 的 即 是 这 种 认证 方式 ; 这 些 令 牌 作为 
Secrets 存 储 在 kube-system 命 名 空间 中 时 ， 可 以 动态 管理 和 创建 它们 ， 而 
Controller Manager 包 含 一 个 TokenCleaner 控 制 器 ， 用 于 删除 过 期 的 引导 
令 蛋 。 


4) 静态 密码 文件 : 用 户 名 和 密码 等 令 牌 以 明文 格式 存储 的 CSV 格 
式 文 件 ， 由 kube-apiserver 使 用 --basic-auth-file 选 项 进行 加 载 ; 客户 端 在 
HTTP basic 认 证 中 将 认证 用 户 的 用 户 名 和 密码 编码 后 以 承载 令 牌 的 格式 
进行 认证 。 


5) 服务 账户 令 牌 : 由 kube-apiserver 自 动 启用 ， 并 可 使 用 可 选 选项 
加 载 --service-account-key-file 验 证 承载 令 牌 的 密 钥 ， 省 略 时 将 使 用 kube- 
apiserver 上 自己 的 证 书 匹 配 的 私 钥 文件 ，Service Account 通 常 由 API Server 
目 动 创建 ， 并 通过 ServiceAccount 准 入 控制 器 将 其 注入 Pod 对 象 ， 包 括 
Service Account 上 的 承载 令 脾 ， 容 器 中 的 应 用 程序 请 求 API Server 的 服务 
时 将 以 此 完成 身份 认证 。 


6) OpenID 连 接 令 牌 : OAuth2 的 一 种 认证 风格 ， 由 Azure AD、 
Salesforce 和 Google 等 ODAuth2 服 务 商 所 文 持 ， 协 议 的 主要 扩展 是 返回 的 
附加 字段 ， 其 中 的 访问 令 牌 也 称 为 ID 令 牌 ， 它 属于 JSON Web 令 牌 

(JWT) 类 型 ， 有 着 服务 器 签名 过 的 常用 字段 ， 如 email 等 ;kube- 
apiserver 启 用 这 种 认证 功能 的 相关 选项 较 多 。 


7) Webhook 令 牌 : HTTP 身 份 验证 允许 将 服务 器 的 URL 注 册 为 
Webhook， 并 接收 带 有 承载 令 牌 的 POST 请 求 进行 身份 认证 ; 客户 端 使 

















用 kubeconfig 格 式 的 配置 文件 ， 在 文件 中 ，“users” 指 的 是 API 服 务 器 
Webhook, “clusters” 指 的 是 API Server。 


8) 认证 代理 : API Server 支 持 从 请 求 首 部 的 值 中 识别 用 户 ， 如 X- 
Remote-User 首 部 ， 它 骨 在 与 身份 验证 代理 服务 相 结合 ， 并 由 该 代理 设 
置 相应 的 请 求 首部 。 


9) Keystone 密 人 码 ; 借助 于 外 部 的 Keystone 服 务 器 进行 身份 认证 。 


10) 匿名 请 求 : 未 被 任何 验证 机 制 明确 拒绝 的 用 户 即 为 匿名 用 户 ， 
其 会 被 自动 标识 为 用 户 名 system: anonymous， 并 隶属 于 system: 
unauthenticated 用 户 组 ; 在 API Server 启 用 了 除 AlwaysAllow 以 外 的 认证 
机 制 时 ， 匿 名 用 户 处 于 启用 状态 ， 不 过 ， 管 理 员 可 通过 --anonymous- 
auth=false 选 项 将 其 禁用 。 


另外 ，API Server 还 允许 用 户 通 过 模拟 〈impersonation) 首部 来 冒充 
另 一 个 用 户 ， 这 些 请 求 可 以 以 手动 的 方式 覆盖 请 求 中 用 于 身份 验证 的 用 
户 信 息 。 例 如 ， 管 理 员 可 以 使 用 此 功能 临时 模拟 其 他 用 户 来 查看 请 求 是 
售 被 拒绝 进行 授权 策略 调试 。 

API Server 是 一 种 REST API， 除 了 身份 认证 信息 之 外 ， 一 个 请 求 报 
文 还 需要 提供 操作 方法 及 其 目标 对 象 ， 如 针对 某 Pod 资 源 对 象 进行 的 创 
建 、 查 看 、 修 改 或 删除 操作 等 ， 具 体 来 说 ， 请 求 报 文 包含 如 下 信息 。 


-API: 用 于 定义 请 求 的 目标 是 否 为 一 个 API 资 源 。 
Request path: 请 求 的 非 资 源 型 路 径 ， 如 /api 或 /healthz。 


.API group: 要 访问 的 API 组 ， 仅 对 资源 型 请 求 有 效 ， 默 认为 “core 
API group”。 
”“Namespace: 目标 资源 所 属 的 名 称 空间 ， 仅 对 隶属 于 名 称 空 间 类 型 
的 资源 有 效 。 
.API request verb: API 请 求 类 的 操作 ， 即 资源 型 请 求 〈 对 资源 执行 
的 操作 ) ， 包 括 get、list、create、update、patch、watch、proxy、 
redirect、delete 和 deletecollection 等 。 


HTTP request verb: HTTP 请 求 类 的 操作 ， 即 非 资源 型 请 求 要 执行 





























的 操作 ， 如 get、post、put 和 delete。 

:Resource: 请 求 的 目标 资源 的 ID 或 名 称 。 

.Subresource: 请 求 的 子 资源 。 

为 了 核验 用 户 的 操作 许可 ， 成 功 通过 身份 认证 后 的 操作 请 求 还 需要 
转交 给 授权 插件 进行 许可 权限 检查 ， 以 确保 其 拥有 执行 相应 的 操作 的 许 
可 。API Server 主 要 支持 使 用 四 类 内 建 的 授权 插件 来 定义 用 户 的 操作 权 
限 。 


:Node: 基于 Pod 资 源 的 目标 调度 节点 来 实现 的 对 kubelet 的 访问 控 
制 | 。 


.ABAC: attribute-based access control， 基 于 属性 的 访问 控制 。 





:RBAC: role-based access control， 基 于 角色 的 访问 控制 。 


`Webhook: 基于 HTTP 回 调 机 制 通过 外 部 REST 服 务 检查 确认 用 户 授 
权 的 访问 控制 。 


另外 ， 还 有 AlwaysDeny 和 AlwaysAllow 两 个 特殊 的 授权 插件 ， 其 中 
AlwaysDeny《〈 总 是 拒绝 ) 仅 用 于 测试 ， 而 AlwaysAllow〈 总 是 允许 ) 则 
用 于 不 期 望 进行 授权 检查 时 直接 于 授权 检查 阶段 放行 的 所 有 操作 请 求 。 
启动 API Server 时 ，“--authorization-mode” 选 项 用 于 定义 要 启用 的 授权 机 
制 ， 多 个 选项 彼此 之 间 以 召 号 分 隔 。 


而 准 入 控制 器 (Admission Controller〉 则 用 于 在 客户 端 请 求 经 过 身 
份 验证 和 授权 检查 之 后 ， 但 在 对 象 持久 化 存储 etcd 之 前 拦截 请 求 ， 用 于 
实现 在 资源 的 创建 、 更 新 和 删除 操作 期 间 强 制 执 行 对 象 的 语义 验证 等 功 
能 ， 读 取 资 源 信 息 的 操作 请 求 不 会 经 由 准 入 控制 器 的 检查 。API Server 
内 置 了 许多 准 入 控制 器 ， 常 用 的 包含 如 下 几 和 种。 不过， 其 中 的 个 别 控制 
器 仅 在 较 新 版 本 的 Kubernetes 中 才 受 支持 。 


1) AlwaysAdmit: 允许 所 有 请 求 。 
2) AlwaysDeny: 拒绝 所 有 请 求 ， 仅 应 该 用 于 测试 。 


3) AlwaysPullImages: 总 是 下 载 镜像 ， 即 每 次 创建 Pod 对 象 之 前 都 

















要 去 下 载 镜 像 ， 币 用 于 多 租户 环境 中 以 确保 私有 镜像 仅 能 够 被 拥有 权限 
的 用 户 使 用 。 


4) NamespaceLifecycle: 拒绝 于 不 存在 的 名 称 空间 中 创建 资源 ， 而 
删除 名 称 空间 将 会 级 联 删 除 其 下 的 所 有 其 他 资源 。 


5) LimitRanger: 可 用 资源 范围 界定 ， 用 于 监控 对 设置 了 
LimitRange 的 对 象 所 发 出 的 所 有 请 求 ， 以 确保 其 资源 请 求 不 会 超 限 。 


6) ServiceAccount: 用 于 实现 Service Account 管 探 机制 的 自动 化 ， 
实现 创建 Pod 对 象 时 目 动 为 其 附加 相关 的 Service Account 对 象 。 


7) PersistentVolumeLabel: 为 那些 由 云 计 算 服 务 商 提供 的 PV 上 自动 附 
加 region 或 zone 标签 ， 以 确保 这 些 存储 卷 能 够 正确 关联 且 仅 能 关联 到 所 
属 的 region 或 zone。 


8) DefaultStorageClass: 监控 所 有 创建 PVC 对 象 的 请 求 ， 以 保证 那 
些 没 有 附加 任何 专用 StorageClass 的 请 求 会 自动 设 定 一 个 默认 值 。 


9) ResourceQuota: 用 于 对 名 称 空间 设置 可 用 资源 的 上 限 ， 并 确保 
在 其 中 创建 的 任何 设置 了 资源 限额 的 对 象 都 不 会 超出 名 称 空 间 的 资源 配 
额 。 














10) DefaultTolerationSeconds: 如 果 Pod 对 象 上 不 存在 污点 宽容 期 
限 ， 则 为 它们 设置 默认 的 宽容 期 ， 以 宽容 “notready: 
NoExecute” 和 和 “unreachable: NoExctute” 类 的 污点 5 分 钟 时 间 。 


11) ValidatingAdmissionWebhook: 并 行 调用 匹配 当前 请 求 的 所 有 
验证 类 的 Webhook， 任 何 一 个 校 验 失败 ， 请 求 即 失败 。 


12) MutatingAdmissionWebhook: 串 行 调 用 匹配 当前 请 求 的 所 有 变 
异类 的 Webhook， 每 个 调用 都 可 能 会 更 改 对 象 。 


早期 的 准 入 控制 占 代 人 码 需 要 由 管理 员 编 译 进 kube-apiserver 中 才能 使 
用 ， 其 实现 方式 缺乏 灵活 性 。 于 是 ，Kubernetes 目 1.7 版 本 引入 了 
Initializers 和 External Admission Webhooks 来 尝试 突破 此 限制 ， 而 且 自 1.9 
版 本 起 ，External Admission Webhooks 被 分 为 MutatingAdmission- 
Webhook 和 ValidatingAdmissionWebhook 两 种 类 型 ， 分 别 用 于 在 API 中 执 


行 对 象 配置 的 变异 和 验证 操作 。 检 碍 期 间 ， 只 有 那些 顺利 通过 所 有 准 入 
控制 喜 检 查 的 资源 操作 请 求 的 结 末 才 能 保存 到 etcd 中 ， 实 现 持 久 存 储 ， 
换 句 话 讲 ， 任 何 一 个 准 入 控制 喜 的 拒绝 都 将 导致 请 求 失败 。 


10.2 ”服务 账户 管理 与 应 用 


运行 过 程 中 ，Pod 资 源 里 的 容器 进程 在 某 些 场景 中 需要 调用 
Kubernetes API 或 者 其 他 类 型 的 服务 ， 而 这 些 服务 通 背 需要 认证 客户 端 
身份 ， 如 调度 器 、Pod 控 制 右 或 节点 控制 堪 ， 甚 至 是 获取 局 动容 句 的 镜 
像 访问 的 私有 Registry 服 务 等 。 服 务 账 户 就 是 用 于 让 Pod 对 象 内 的 容器 进 
程 访问 其 他 服务 时 提供 身份 认证 信息 的 账户 。 一 个 Service Account 资 源 
一 般 由 用 户 名 及 相关 的 Secret 对 象 组 成 。 








10.2.1 Service Account 自 动 化 


细心 的 读者 或 许 已 经 注意 到 ， 此 前 创建 的 每 个 Pod 资 源 都 目 动 关联 
了 一 个 存储 卷 ， 并 由 其 容器 挂 载 
至 /var/run/secrets/kubernetes.io/serviceaccount 有 目录 ， 例 如 ， 下 面 
由 “kubectl describe pod” 命 令 显示 的 某 Pod 对 象 描述 信息 的 片断 : 





Containers : 
Mounts: 
/var/run/secrets/kubernetes.io/serviceaccount from default-token-bq6zc (ro) 


Volumes: 


default-token-bq6zc: 
Type: Secret (a volume populated by a Secret) 
SecretName: default-token-bq6zc 
Optional: false 








挂 载 点 目录 中 通常 存在 三 个 文件 : ca.crt、namespace 和 token， 其 
中 ，token 文 件 保存 了 Service Account 的 认证 token， 容 器 中 的 进程 使 用 它 
癌 API Server 发 起 连接 请 求 ， 进 而 由 认证 插件 完成 用 户 认 证 并 将 其 用 户 
名 传递 给 授权 插件 。 


每 个 Pod 对 象 都 只 有 一 个 服务 账户 ， 夺 创建 Pod 资 源 时 未 予以 明确 指 
定 ， 则 名 为 ServiceAccount 的 准 入 控制 器 会 为 其 自动 附加 当前 名 称 空 间 
中 默认 的 服务 账户 ， 其 名 称 通常 为 default。 下 面 的 命令 显示 了 了 default 这 
个 服务 账户 的 详细 信息 : 





~]$ kubect1 describe serviceaccount default 


Name : default 
Mountable secrets: default-token-bq6zc 
Tokens : default-token-bq6zc 
Events: <none> 





Kubernetes 系 统 通 过 三 个 独立 的 组 件 间 的 相互 协作 来 实现 服务 账户 

的 自动 化 ， 三 个 组 件 具 体 为 : Service Account 准 入 控制 器 、 令 有 牌 控制 器 

(token controller) 和 Service Account 账 户 控制 器 。Service Account 控 制 
器 负责 为 名 称 空间 管理 相应 的 资源 ， 并 确保 每 个 名 称 空间 中 都 存在 一 个 








名 为 “default” 的 Service Account 对 象 。Service Account 准 入 控制 器 是 API 
Server 的 一 部 分 ， 负 责 在 创建 或 更 新 Pod 时 对 其 按 需 进行 Service Account 
对 象 相 关 信 息 的 修改 ， 这 包括 如 下 操作 。 


.和 若 Pod 没 有 明确 定义 使 用 的 ServiceAccount 对 象 ， 则 将 其 设置 
为 “default”。 


.确保 Pod 明 确 引用 的 ServiceAccount 已 存在 ， 和 否则 请 求 将 被 拒绝 。 


. 行 Pod 对 象 中 不 包含 ImagePullSecerts， 则 把 Service Account 的 
ImagePullSecrets 添 加 于 其 上 。 


:为 禹 有 访 问 API 的 令 牌 的 Pod 添 加 一 个 存储 卷 。 


:为 Pod 对 象 中 的 每 个 容器 添加 一 个 volumeMounts， 挂 载 
至 /var/run/secrets/kubernetes.io/serviceaccount。 


令 牌 控制 器 是 controller-manager 的 子 组 件 ， 工 作 于 异步 模式 。 其 负 
责 完 成 的 任务 具体 如 下 。 


监控 Service Account 的 创建 操作 ， 并 为 其 添加 用 于 访问 API 的 Secret 
对 象 。 


.监控 Service Account 的 删除 操作 ， 并 删除 其 相关 的 所 有 Service 


Account 令 牌 密 铀 。 


.监控 Secret 对 象 的 添加 操作 ， 确 保 其 引用 的 Service Account 已 存 
在 ， 并 在 必要 时 为 Secret 对 象 添 加 认证 令 牌 。 


.监控 Secret 对 象 的 删除 操作 ， 以 确保 删除 每 个 Service Account 中 对 
此 Secret 的 引用 。 


需要 注意 的 是 ， 为 确保 完整 性 等 ， 必 须 为 kube-controller-manager 使 
用 “--service-account-private-key-file” 选 项 指定 一 个 私 钥 文 件 ， 以 用 于 对 
生成 的 服务 账户 令 牌 进行 签名 ， 此 私 钥 文件 必须 是 pem 格 式 。 类 似 地 ， 
还 要 为 kube-apiserver 使 用 “--service-account-key-file” 指 定 与 前 面 的 私 钥 
配对 儿 的 公 钥 文件 ， 以 用 于 在 认证 期 间 对 认证 令 牌 进行 校 验 。 











10.2.2 ”创建 服务 账户 


Service Account 是 Kubernetes API 上 的 一 种 资源 类 型 ， 它 隶属 于 名 称 
空间 ， 用 于 让 Pod 对 象 内 部 的 应 用 程序 在 与 API Server 通 信 时 完成 身份 认 
证 。 事 实 上 ， 每 个 名 称 空间 都 有 一 个 名 为 default 的 默认 资源 对 象 ， 如 下 
面 的 命令 及 其 结果 所 示 ， 其 可 用 于 让 Pod 对 象 有 权限 读 取 同一 名 称 空间 
中 的 其 他 资源 对 象 的 元 数据 信息 。 需 要 赋予 Pod 对 象 更 多 操作 权限 时 ， 
则 应 该 由 用 户 按 需 创建 目 定 义 的 Service Account 资 源 : 





~]$ kubect1 get serviceaccounts --all-namespaces 


NAMESPACE NAME SECRETS AGE 
default default 1 2h 
kube-public default 1 2h 
kube-system default 1 2h 





每 个 Pod 对 象 均 可 附加 其 所 属 名 称 空间 中 的 一 个 Service Account 资 
源 ， 且 只 能 附加 一 个 。 不 过 ， 一 个 Service Account 资 源 可 由 其 所 属 名 称 
空间 中 的 多 个 Pod 对 象 共享 使 用 。 创 建 Pod 资 源 时 ， 用 户 可 使 
用 “spec.serviceAccountrName” 属 性 直接 指定 要 使 用 的 Service Account 对 
象 ， 或 者 省 略 此 字段 而 由 其 自动 附加 当前 名 称 空 间 中 默认 的 Service 


Account (default) 。 


可 使 用 资源 配置 文件 创建 Service Account 资源， 也 可 直接 使 
用 “kubectl create servic-eaccount” 命 令 进 行 创 建 ， 提 供认 证 令 牌 的 Secret 
对 象 会 由 命令 自动 创建 完成 。 下 面 的 配置 清单 是 一 个 ServiceAccount 资 
源 示例 ， 它 仅 指定 了 创建 名 为 sa-demo 的 服务 账户 ， 其 余 的 信息 则 交 由 
系统 自动 生成 : 








apiVersion: v1 
kind: ServiceAccount 
metadata: 
name: sa-demo 
namespace: default 





创建 Pod 对 象 时 ， 可 为 Pod 对 象 指 定 使 用 自 定义 的 服务 账户 ， 从 而 实 
现 自主 控制 Pod 对 象 资源 的 访问 权限 。Pod 疝 API Server 发 出 请 求 时 ， 其 
携带 的 认证 令 牌 在 通过 认证 后 将 由 授权 插件 来 判定 相关 的 Service 





Account 是 否 有 权限 访问 其 所 请 求 的 资源 。Kubernetes 文 持 多 种 授权 插 
件 ， 由 管理 员 负 责 选 定 及 配置 ，RBAC 是 目前 较为 主流 的 选择 。 





10.2.3 ”调用 imagePullSecret 资 源 对 象 


ServiceAccount 资 源 还 可 以 基于 spec.imagePullSecret 字 段 附 带 一 个 由 
下 载 镜 像 专 用 的 Secret 资 源 组 成 的 列表 ， 用 于 在 进行 容器 创建 时 ， 从 某 
私有 镜像 仓库 下 载 锐 像 文件 之 前 进行 服务 认证 。 下 面 的 示例 定义 了 一 个 
有 着 从 本 地 私有 镜像 仓库 harbor 中 下 载 镜像 文件 时 用 于 认证 的 Secret 对 象 


信息 的 ServiceAccount: 





apiVersion: v1 
kind: ServiceAccount 
metadata: 

name: image-download-sa 
imagePullSecrets: 
- Name: local-harbor-secret 





其 中 ，local-harbor-secret 是 docker-registry 类 型 的 Secret 对 象 ， 由 用 户 
提前 手动 创建 ， 它 可 以 通过 键 值 数据 提供 docker 仓 库 服 务 器 的 地 址 、 接 
入 服务 器 的 用 户 名 、 密 码 及 用 户 的 电子 邮件 等 信息 。 认 证 通过 后 ， 引 用 
了 此 ServiceAccount 的 Pod 资 源 即 可 从 指定 的 镜像 仓库 中 下 载 由 image 字 
段 指 定 的 镜像 文件 。 


10.3 XX.509 数 字 证 书 认证 


Kubernetes 支 持 的 HTTPS 客 户 端 证 书 认证 、token 认 证 及 HTTP basic 
认证 几 种 认证 方式 中 ， 基 于 SSL/TLS 协 议 的 客户 端 证 书 认证 以 其 安全 性 
高 且 易 于 实现 等 特性 ， 而 成 为 主要 使 用 的 认证 方式 之 一 。 


SSL/TLS 最 常见 的 使 用 场景 是 将 X.509 证 书 与 服务 器 端 相 关联 ， 但 
不 为 客户 端 使 用 证 书 。 这 意味 着 客户 端 可 以 验证 服务 端的 身份 ， 但 服务 
端 无 法 验证 客户 端的 身份 (至 少 不 能 通过 SSL/TLS 协 议 进行 )。 这 很 容 
易 理 解 ， 毕 竟 SSL/TLS 安 全 性 最 初 是 为 互联 网 应 用 开发 ， 保 护 客户 端 反 
而 是 高 优先 级 的 需求 ， 例 如 ， 在 需要 连接 到 银行 的 网 站 时 需要 确保 该 网 
站 是 真实 的 等 ， 如 图 10-2 所 示 。 


此 外 ， 验 证 客户 器 时 ， 使 用 其 他 机 制 “ 如 HITP 基 本 认证 ) 通 秆 会 
更 容易 些 ， 而 且 这 些 机 制 不 会 产生 生成 和 分 发 X.509 证 书 的 高 昂 维护 开 
销 。 不 过 ， 安 全 性 有 要求 较 高 的 场景 中 ， 使 用 组 织 私 有 的 证 书 分 用 系 统 也 
一 样 能 够 使 用 数字 证 书 进行 客户 并 认证 。 图 10-3 展 示 了 服务 端 与 客户 端 
的 双 同 认证 机 制 。 


服务 器 与 客 尸 端 互相 认证 的 场景 中 ， 双 方 各 目 需要 配备 一 僚 证 书 ， 
并 拥有 信任 的 签证 机 构 的 证 书 列 表 。 使 用 私有 签证 机 构 颁 发 的 数字 证 书 
0 
用 
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图 10-2 ”SSL/TLS 服 务 端 认 证 (图 片 来 源 : Red Hat Inc.) 
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图 10-3 SSL/TLS 双 向 认证 (图 片 来 源 : Red Hat Inc.) 


10.3.1 Kubernetes 中 的 SSL/TLS 认 证 


构建 安全 基础 通信 环境 的 Kubernetes 集 群 时 ， 需 要 用 到 TLS 及 数字 
证 书 的 通信 场景 有 很 多 种 ， 如 图 10-4 所 示 。API Server 是 整个 Kubernetes 
集群 的 通信 网 关 ，controller-manager、scheduler、kubelet 及 kube-proxy 等 
均 需 要 经 由 API Server 与 etcd 通 信 完 成 资源 状态 信息 的 获取 及 更 新 等 。 同 
样 出 于 安全 通信 的 目的 ，master 的 各 组 件 (API Server、controller- 
manager 和 scheduler) 需要 基于 SSL/TLS 向 外 提供 服务 ， 而 且 与 集群 内 部 
组 件 间 进行 通信 时 (主要 是 各 节点 上 的 kubelet 和 kube-proxy)〉 还 需要 进 
行 双 辣 身份 验证 。 
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图 10-4 ”Kubernetes 的 SSL/TLS 通 信 


Kubernetes 集 群 中 各 资源 的 状态 信息 ， 包 括 Secret 对 象 中 的 敏感 信息 
等 均 以 明文 方式 存储 于 etcd 中 ， 因 此 ，etcd 和 集群 内 各 节点 间 的 通信 ， 以 
及 各 节点 与 其 客户 端 (主要 是 API sevrver) 之 间 的 通信 都 应 该 以 加 密 的 
方式 进行 ， 并 需 进 行 身份 验证 。 


1) etcd 集 群 内 对 等 节点 通信 :，etcd 集 群 内 各 节点 间 的 集群 事务 通 
信 ， 默 认 监 听 于 TCP 的 2380 端 口 ， 基 于 SSL/TLS 通 信 时 需要 peer 类 型 的 
数字 证 书 ， 可 实现 节点 间 的 身份 认证 及 通信 安全 ， 这 些 证 书 需要 由 一 个 
专用 CA 进行 管理 。 





2) etcd 服 务 器 与 客户 端 通信 : etcd 的 REST API 服 务 ， 默 认 监 听 于 
TCP 的 2379 端 口 ， 用 于 接收 并 啊 应 客户 端 请 求 ， 基 于 SSL/TLS 通 信 ， 文 
持 服 务 端 认证 和 双向 认证 ， 而 且 要 使 用 一 个 专用 CA 来 管理 此 类 证 书 ; 
kube-apiserver 就 是 etcd 服 务 的 主要 客户 端 。 


API Server 与 其 客户 端 之 间 采 用 HTTPS 通 信 可 兼顾 实现 通信 和 与 认证 
的 功能 ， 它 们 之 间 通 信 的 证 书 可 由 同一 个 CA 进行 管理 ， 其 客户 端 大 体 
可 以 分 为 如 下 三 类 。 


.控制 平面 的 kube-scheduler 和 kube-controller-manager。 

:工作 节点 组 件 kubelet 和 kube-proxy: 初次 接 入 集群 时 ，kubelet 可 自 
动 生成 私 钥 和 证 书签 署 请 求 ， 并 由 Master 为 其 自动 进行 证 书签 名 和 颁 
发 ， 这 就 是 所 谓 的 ts bootstraping。 

kubelet 及 其 他 形式 的 客户 问 ， 如 Pod 对 象 等 。 

集群 上 运行 的 应 用 (Pod) 同 其 客户 端的 通信 经 由 不 可 信 的 网络 传 


输 时 也 可 能 需要 用 到 TLS/SSL 协 议 ， 如 Nginx Pod 与 其 客户 端 间 的 通信 ， 
客户 端 来 自 于 互联 网 时 ， 此 处 通常 需要 配置 一 个 公信 的 服务 端 证 书 。 





10.3.2 ”客户 问 配 置 文件 kubeconfig 


包括 kubectl、kubelet 和 kube-controller-manager 等 在 内 的 API Server 
的 各 类 客户 端 都 可 以 使 用 kubeconfig 配 置 文件 提供 接 入 多 个 集群 的 相关 
配置 信息 ， 包 括 各 API Server 的 URL 及 认证 信息 等 ， 而 且 能 够 设置 成 不 
同 的 上 下 文 环 境 ， 并 在 各 环境 之 间 快 速 切换 ， 如 网 10-5 所 示 。 
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图 10-5 kubectl 和 kubeconf ig 


使 用 kubeadm 初 始 集群 后 生成 的 /etc/kubernetes/admin.conf 文 件 即 为 
kubeconfig 格 式 的 配置 文件 ， 其 由 kubeadm init 命 令 目 动 生 成 ， 可 由 
kubectl 加 载 (默认 路 径 为 $4HOME/.kube/config〉 后 用 于 接 入 服务 
器 。“kubectl config view” 命 令 能 够 显示 当前 正在 使 用 的 配置 文件 ， 下 面 
的 命令 结果 打印 了 文件 中 配置 的 集群 列表 、 用 户 列表 、 上 下 文 列表 以 及 
当前 使 用 的 上 下 文 《current-context〉 等 : 





[root@master ~]# kubectl1 config view 
apiVersion: v1 
clusters: 
- Cluster: 
certificate-authority-data: REDACTED 
server: https://172.16.0.70:6443 
name: kubernetes 
Contexts : 
- Context : 
cluster: kubernetes 
user: kubernetes-admin 
name: kubernetes-admin@kubernetes 
current-context: kubernetes-admin@kubernetes 
kind: Config 
preferences: {} 
Users: 
- name: kubernetes-admin 
User: 


client-certificate-data: REDACTED 
client-key-data: REDACTED 





事实 上 ， 任 何 类 型 的 API Server 客 户 端 都 可 以 使 用 kubeconfig 进 行 配 
置 ， 例 如 KubernetesNode 之 上 的 kubelet 和 kube-proxy 也 需要 将 其 用 到 的 
认证 信息 保存 于 专用 的 kubeconfig 文 件 中 ， 并 通过 --kubeconfig 选 项 进行 
加 载 。kubeconfig 文 件 的 定义 中 包含 以 下 几 项 主要 的 配置 ， 它 们 彼此 之 
间 的 关系 表示 也 由 图 10-6 给 出 了 。 


:clusters: 集群 列表 ， 包 含 访问 API Server 的 URL 和 所 属 集群 的 名 称 


掉 


:users: 用 户 列 表 ， 包 含 访问 API Server 时 的 用 户 名 和 认证 信息 。 


contexts: kubelet 的 可 用 上 下 文 列 表 ， 由 用 户 列 表 中 的 某 特 定 用 户 
名 称 和 和 集群 列表 中 的 某 特定 集群 名 称 组 合 而 成 。 


:current-context: kubelet 当 前 使 用 的 上 下 文 名 称 ， 即 上 下 文 列表 中 
的 某 个 特定 项 。 
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图 10-6 ”kubeconfig 文 件 格 式 示 意图 


用 户 也 可 以 按 需 自 定 义 相 关 的 配置 信息 于 kubeconfig 配 置 文件 中 ， 
能 。kubeconfig 是 一 个 文本 文 





以 实现 使 用 不 同 的 用 户 账 户 接 入 集群 等 功能 
件 ， 虽 然 支持 使 用 文本 处 理工 具 直 接 进 行 编辑 ， 但 这 里 建议 用 户 使 
够 自动 进行 语法 检测 等 额外 功 


"命令 进行 设 定 ， 它 能 


用 “kubectl config 
能 。kubectl config 命 令 的 常用 操作 包含 如 下 几 项 。 
:kubect] config view: 打印 kubeconfig 文 件 内 容 。 
.kubectl config set-cluster: 设置 kubeconfig 的 clusters 配 置 段 。 


.kubectl config set-credentials: 设置 kubeconfig 的 users 配 置 段 。 


.kubectl config set-context: 设置 kubeconfig 的 contexts 配 置 段 。 


.kubectl config use-context: 设置 kubeconfig 的 current-context 配 置 


段 。 


使 用 kubeadm 部 署 的 Kubernetes 集 群 默 认 提 供 了 拥有 集群 管理 权限 
的 kubeconfig 配 置 文件 /etc/kubernetes/admin.conf， 它 可 被 复制 到 任何 有 
着 kubectl 的 主机 上 以 用 于 管理 整个 集群 。 除 此 之 外 ， 管 理 员 还 可 以 创建 
其 他 基于 SSL/TLS 认 证 的 自 定义 用 户 账 号， 以 授予 非 管理 员 级 的 集群 资 
源 使 用 权限 ， 其 配置 过 程 由 两 部 分 组 成 : 一 是 为 用 户 创建 专用 私 钥 及 证 
书 文 件 ， 二 是 将 其 配置 于 某 kubeconfig 文 件 中 。 下 面 给 出 其 具体 的 实现 
过 程 ， 并 借 此 创建 将 一 个 测试 用 户 kube-user1 用 于 后 文中 的 授权 测试 。 


第 一 步 ， 为 目标 用 户 账 号 kube-user1 创 建 私 钥 及 证 书 文件 ， 保 存 
于 /etc/kubernetes/pki 目 录 中 。 





@ 提示 “本 步骤 中 的 操作 需要 在 Master 节 点 上 以 root 用 户 的 身份 
执行 。 
1) 生成 私 钥 文件 ， 注 意 其 权限 应 该 为 600 以 阻止 其 他 用 户 随 意 获 


取 ， 这 里 在 Master 节 点 上 以 root 用 户 进 行 操作 ， 并 将 文件 放置 
于 /etc/kubernetes/pki 专 用 目录 中 : 








~]# cd /etc/kubernetes/pki 
~]# (umask 077; openssl genrsa -out kube-useri1.key 2048) 





2) 创建 证 书签 署 请 求 ，-subj 选 项 中 CN 的 值 将 被 kubeconfig 作 为 用 
户 名 使 用 ，O 的 值 将 被 识别 为 用 户 组 : 





~]# openssl req -new -key kube-useri.key -out kube-useri1.csr -Subj "/CN=kube-user1/ 
0=kubeusers" 





3) 基于 kubeadm 安 装 Kubermnetes 和 集群 时 生成 的 CA 签署 证 书 ， 这 里 设 
置 其 有 效 时 长 为 3650 天 : 





~]# openssl x509 -req -in kube-useri.csr -CA ca.crt -CAkey ca.key \ 


-CAcreateserial -out kube-useri1.crt -days 3650 





4) 验证 证 书信 息 〈 可 选 ) : 





~]# openssl x509 -in kube-useri.crt -text -noout 





第 二 步 ， 以 默认 的 管理 员 kubernetes-admin@kubernetes 为 新 建 的 
kube-user1l 设 定 kube-config 配 置 文件 。 配 置 结果 将 默认 保存 于 当前 系统 
用 户 的 .kube/config 文 件 中 ， 当 然 也 可 以 为 kubectl 使 用 --kubeconfig 选 项 指 
定 目 定义 的 专用 文件 路 径 。 


1) 配置 集群 信息 ， 包 括 集 群 名 称 、API Server URL 和 CA 证 书 ， 若 
集群 信息 已 然 存 在 ， 则 可 省 略 此 步 ， 另 外 ， 提 供 的 新 配置 不 能 与 现 有 本 
置 中 的 集群 名 称 相 同 ， 否 则 将 覆盖 它们 : 








~]$ kubect1 config set-cluster kubernetes --embed-certs=true \ 
--certificate-authority=/etc/kubernetes/pki/ca.crt --server="https://172.16. 
0.70:6443" 





2) 配置 客户 端 证 书 及 密 钥 ， 用 户 名 信息 会 通过 命令 从 证 书 Subject 
的 CN 值 中 自动 提取 ， 例 如 前 面 创建 csr 时 使 用 的 “CN=kube-user1”， 而 组 
名 则 来 自 于 “O=kubeusers” 的 定义 : 





~]$ kubect1 config set-credentials kube-user1 --embed-certs=true \ 
--client-certificate=/etc/kubernetes/pki/kube-useri.crt \ 
--client-key=/etc/kubernetes/pki/kube-useri1.key 





3) 配置 context， 用 来 组 合 cluster 和 credentials， 即 访问 的 集群 的 上 
下 文 。 如 果 为 管理 多 个 集群 而 设置 了 多 个 环境 ， 则 可 以 使 用 use-context 
来 进行 切换 : 





~]$ kubect1 config set-context kube-useri@kubernetes --cluster=kubernetes --USer= 
kube-user1 





4) 最 后 指定 要 使 用 的 上 下 文 ， 切换 为 以 kube-user1l 访 问 集群 : 





~]$ kubect1 config use-context kube-user1l1Q@kubernetes 





5) 测试 访问 集群 资源 ， 不 过 在 启用 RBAC 的 集群 上 执行 命令 时 ， 
kube-user1 并 未 获得 集群 资源 的 访问 权限 ， 因 此 会 出 现 错误 提示 : 





~]$ kubectl1 get pods 
Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list pod: 
in the namespace "default" 








此 时 ， 知 需 切 换 至 管理 员 账 号 ， 则 可 使 用 “kubectl config use-context 
kubernetes-admin(@kubernetes” 命 令 来 完成 。 男 外 ， 临 时 使 用 某 context 
时 ， 不 必 设 置 current-context， 只 需要 为 kubectl 命 令 使 用 --context 选 项 指 
定 目 标 context 的 名 称 即 可 ， 如 “kubectl--context= kube-user1@kubernetes 
get pods”。 


10.3.3 ”TLS bootstrapping 机 制 








新 的 工作 节点 接 入 集群 时 需要 事先 配置 好 相关 的 证 书 和 私 钥 等 以 进 
行 安全 通信 ， 管 理 员 既 可 以 手动 提供 相关 的 配置 ， 也 可 以 选择 由 kubelet 
自行 生成 私 铀 和 自 签 证 书 。 集 群 略 具 规 模 后 ， 第 一 种 方式 无 疑 会 为 管理 
员 融 来 不 小 的 负担 ， 但 其 对 于 保障 集群 安全 运行 却 又 必 不 可 少 。 第 二 种 
方式 降低 了 管理 员 的 工作 量 ， 却 也 损失 了 PKI 本 喘 所 具有 的 诸多 优势 。 
综合 上 述 两 种 方案 ， 取 长 补 短 之 后 ，Kubernetes 采 用 了 一 种 新 的 方案 : 
由 kubelet 自 行 生 成 私 铀 和 证 书签 晋 请 求 ， 而 后 发 送 给 集群 上 的 证 书签 署 
进程 《CA) ， 由 管理 员 验 证 请 求 后 予以 签 普 或 直接 控制 右 进 程 自 动 统 
一 签署 。 这 种 方式 即 为 Kubelet TLS Bootstrapping 机 制 ， 它 实现 了 前 述 第 
一 种 方式 的 功能 ， 却 基本 上 不 会 增加 管理 员工 作 量 。 


然而 ， 局 用 了 kubelet bootstrap 功 能 之 后 ， 任 何 kubelet 进 程 都 可 以 向 
API Server 发 起 签证 请 求 并 加 入 到 集群 中 ， 包 括 那些 来 自 于 非 计 划 或 非 
授权 主机 的 kubelet， 这 必 将 增 大 管理 签证 操作 时 的 识别 工作 量 。 此 时 ， 
就 需要 配合 使 用 某 种 认证 机 制 对 发 出 请 求 的 kubelet 加 以 认证 ， 而 后 仪 放 
行 那些 通过 认证 的 签证 请 求 。API Server 使 用 了 一 个 基于 认证 令 牌 
对 “system: bootstrappers” 组 内 的 用 户 完 成 认证 的 认证 器 。controller- 
manager 会 用 到 这 个 用 户 组 配置 默认 的 审批 控制 占 (approval controller) 
适用 的 审批 范围 ， 它 依赖 于 由 管理 员 将 此 token 正 确 绑 定 于 RBAC 策 略 ， 
以 限制 其 仅 能 用 于 签证 操作 相关 的 流程 之 中 。 




















@ 提示 。 kubeadm 启 用 了 节点 加 入 集群 时 的 证 书 自 动 签 车 功 
能 ， 因 此 加 入 过 程 在 kubeadm join 命 令 成 功 后 即 完成 。 


请 求证 书 时 ，kubelet 要 使 用 含有 bootstrap token 的 kubeconfig 文 件 问 
kube-apiserver 发 送 请 求 ， 此 kubeconfig 在 credentials 中 指定 要 调用 的 token 
文件 名 称 必 须 是 kubelet-bootstrap 。 知 指定 的 kubeocnfig 配 置 文件 不 存 
在 ， 则 kubelet 会 转 而 使 用 bootstrap token 从 API Server 中 自动 请 求证 书 。 
证 书 请 求 审批 通过 后 ，kubelet 把 接收 到 的 证 书 和 私 钥 的 相关 信息 存储 
于 --kubeconfig 选 项 指定 的 文件 中 ， 而 证 书 和 私 钥 文件 则 存储 于 --cert-dir 
选项 指定 的 目录 下 。 


kube-controller-manager 内 部 有 一 个 用 于 证 书 颁发 的 控制 循环 ， 它 是 


末 用 了 类 似 于 cfssl 签 证 器 格式 的 自动 签证 器 ， 颁 发 的 所 有 证 书 都 仪 有 一 
年 有 效 期 限 。 签 证 依赖 于 CA 提供 加 密 组 件 支 撑 ， 此 CA 还 必须 被 kube- 
apiserver 的 “--client-ca-file” 选 项 指定 的 CA 信任 以 用 于 认证 。 


Kubernetes 1.8 之 后 的 版 本 中 使 用 的 csrapproving 审 批 控 制 嚣 内置 于 
kube-controller-manager 中 ， 并 且 默 认为 启用 状态 。 此 审批 控制 占 使 用 
SubjectAccessview API 确 认 给 定 的 用 户 是 否 有 权限 请 求 CSR 证 书签 署 
请 求 ) ， 而 后 再 根据 授权 结果 判定 是 否 予 以 签署 。 不 过 ， 为 了 避免 同 其 
他 审批 器 发 生 冲 突 ， 内 建 的 审批 器 并 不 显 式 拒绝 CSR， 而 只 是 忽略 它 
们 : 





10.4 基于 角色 的 访问 控制 : RBAC 


RBAC (Role-Based Access Control， 基 于 角色 的 访问 控制 ) 是 一 种 
新 型 、 灵 活 且 使 用 广泛 的 访问 控制 机 制 ， 它 将 权限 授予 “角色 ” (role) 
Sa 这 一 点 有 别 于 传统 访问 控制 机 制 中 将 权限 直接 赋予 使 用 者 的 方 


在 RBAC 中 ， 用 户 (User) 就 是 一 个 可 以 独立 访问 计算 机 系统 中 的 
数据 或 者 用 数据 表示 的 其 他 资源 的 主体 〈Subject) 。 角 色 是 指 一 个 组 织 
或 任务 中 的 工作 或 者 位 置 ， 它 代表 了 一 种 权利 、 资 格 和 责任 。 许 可 
(Permission) 就 是 允许 对 一 个 或 多 个 客体 〈Object) 执行 的 操作 。 一 个 
用 户 可 经 授权 而 拥有 多 个 角色 ， 一 个 角色 可 由 多 个 用 户 构成 ; 每 个 角色 
可 拥有 多 种 许可 ， 每 个 许可 也 可 授权 给 多 个 不 同 的 角色 。 每 个 操作 可 施 
加 于 多 个 客体 〈 受 控 对 象 ) ， 每 个 客体 也 可 以 接受 多 个 操作 。RBAC 中 
的 动作 、 主 体 及 客体 如 图 10-7 所 示 。 


订 一 @ 


Subject Object 
图 10-7 RBAC 中 的 主体 、 动 作 及 客体 


如 其 名 字 所 示 ，RBAC 的 基于 “角色 ”(role) 这 一 核心 组 件 实 现 了 权 
限 指派 ， 有 具体 实现 中 ， 它 为 账号 赋予 一 到 多 个 角色 从 而 让 其 具有 角色 之 
上 的 权限 ， 其 中 的 账号 可 以 是 用 户 账号 、 用 户 组 、 服 务 账 号 及 其 相关 的 
组 等 ， 而 同时 关联 至 多 个 角色 的 账号 所 拥有 的 权限 是 多 个 角色 之 上 的 权 
限 集 合 。RBAC 中 的 用 户 、 角 色 及 权限 的 关系 如 图 10-8 所 示 。 


























图 10-8 RBAC 中 的 用 户 、 角 色 及 权限 


10.4.1 RBAC 授 权 插 件 


RBAC 是 一 种 操作 授权 机 制 ， 用 于 界定 “ 谁 ”(subject)〉 能 够 或 不 能 
够 “操作 ”(verb〉 哪个 或 哪 类 “对 象 ”(object) 。 动 作 的 发 出 者 即 “ 主 
体 ”"， 通 和 常 以 “账号 ”为 载体 ， 它 既 可 以 是 常规 用 户 (User Account) ， 也 
可 以 是 服务 账号 (Service Account) 。 “操作 ”(verb ) 用 于 表明 要 执行 
的 具体 操作 ， 包 括 创 建 、 删 除 、 修 改 和 查看 等 ， 对 应 于 kubectl 来 说 ， 它 
通常 由 create、apply、delete、update、patch、edit 和 get 等 子 命令 来 给 
出 。 而 “客体 ” 则 是 指 操作 施加 于 的 目标 实体 ， 对 Kubernetes API 来 说 主 
要 是 指 各 类 的 资源 对 象 以 及 非 资源 型 URL。 





@ 提示 。 Kubernetes 自 1.5 版 起 引入 RBAC，1.6 版 本 中 将 其 升级 
为 Beta 级 别 ， 并 成 为 kubeadm 安 装 方式 下 的 默认 选项 。 而 后 ， 直 到 1.8 版 
本 ， 它 才 正 式 升级 为 stable 级 别 。 

相对 于 ABAC 和 Webhook 等 授权 机 制 来 说 ，RBAC 上 共有 如 下 优势 。 

1) 对 集群 中 的 资源 和 非 资 源 型 URL 的 权限 实现 了 完整 履 盖 。 


2) 整个 RBAC 完 全 由 少数 几 个 API 对 象 实 现 ， 而 且 同 其 他 API 对 象 
一 样 可 以 用 kubectl 或 API 调 用 进行 操作 。 


3) 支持 权限 的 运行 时 调整 ， 无 须 重新 启动 API Server。 
API Server 是 RESTful 风 格 的 API， 各 类 客户 端 基 于 HTTP 的 请 求 报 文 
(首部 ) 发 送 身 份 认证 信息 并 由 认证 插件 完成 身份 验证 ， 而 后 通过 
HTTP 的 请 求 方法 指定 对 目标 对 象 的 操作 请 求 并 由 授权 插件 进行 授权 检 
查 ， 而 操作 的 对 象 则 是 借助 UREL 路 径 指 定 的 REST 资 源 。 


图 10-9 对 比 给 出 了 HTTP Verb 和 Kubernetes APIServer Verb 的 对 应 关 





HTTPverb request verb 


create 

get (for individual resources), list (for collections) 
PUT update 
PATCH patch 


DELETE delete (for individual resources), deletecollection (for collections) 





图 10-9 HTTP Verb 与 API Server Verb 
图 10-10 所 描述 的 过 程 中 ， 运 行 于 API Server 之 上 的 授权 插件 RBAC 


负责 确定 某 账号 是 否 有 权限 对 目标 资源 发 出 指定 的 操作 ， 它 们 都 属 
于 “许可 ”(permission) 类 型 的 授权 ， 不 存在 任何 “拒绝 ”权限 。 




























Human User GET 


HEAD 


/api/vl/pods/pod!1 
PUT /apl/vl/pods/pod2 
POST /apl/vl/services/svel 
PATCH 


DELETE 





Pod 
Service Account 


图 10-10 ”Kubernetes RBAC 简 要 模型 


RBAC 授 权 插 件 支 持 Role 和 ClusterRole 两 类 角色 ， 其 中 Role 作 用 于 
名 称 空间 级 别 ， 用 于 定义 名 称 空间 内 的 资源 权限 集合 ， 而 ClusterRole 则 
用 于 组 织 集群 级 别 的 资源 权限 集合 ， 它 们 都 是 标准 的 API 资 源 类 型 。 一 
般 来 说 ，ClusterRole 的 许可 授权 作用 于 整个 集群 ， 因 此 第 用 于 控制 Role 
无 法 生效 的 资源 类 型 ， 这 包括 集群 级 别 的 资源 〈 如 Nodes) 、 非 资源 类 
型 的 端点 《如 healthz) 和 作用 于 所 有 名 称 空 间 的 资源 《〈 例 如， 路 名 称 空 
间 获 取 任 何 资源 的 权限 ) 。 


对 这 两 类 角色 进行 赋 权 时 ， 需 要 用 到 RoleBinding 和 
ClusterRoleBinding 这 两 种 资源 类 型 。RoleBinding 用 于 将 Role 上 的 许可 权 
限 绑 定 到 一 个 或 一 组 用 户 之 上 ， 它 隶属 于 且 仅 能 作用 于 一 个 名 称 空 间 。 
绑 定 时 ， 可 以 引用 同一 名 称 中 的 Role， 也 可 以 引用 集群 级 别 的 
ClusterRole。 而 ClusterRoleBinding 则 把 ClusterRole 中 定义 的 许可 权限 绑 
定 在 一 个 或 一 组 用 户 之 上 ， 它 仅 可 以 引用 集群 级 别 的 ClusterRole。 
Role、RoleBinding、ClusterRole 和 ClusterRoleBinding 的 关系 如 图 10-11 所 
示 。 





Cluster scope (resource that aren t namespaced) 


Namespace A 


RoleBinding 





ClusterRoleBinding 


ClusterRole 
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RoleBinding se 





图 10-11 Role、RoleBinding、ClusterRole 和 ClusterRoleBinding 


一 个 名 称 空间 中 可 以 包含 多 个 Role 和 RoleBinding 对 象 ， 类 似 地 ， 集 
群 级 别 也 可 以 同时 存在 多 个 ClusterRole 和 ClusterRoleBinding 对 象 。 而 一 
个 账户 也 可 经 由 RoleBinding 或 ClusterRoleBinding 关 联 至 多 个 角色 ， 从 而 
具有 多 重 许 可 授权 。 





10.4.2 Role 和 RoleBinding 


Role 仅 是 一 组 许可 〈permission) 权限 的 集合 ， 它 描述 了 对 哪些 资 
源 可 执行 何 种 操作 ， 资 源 配置 清单 中 使 用 rules 字 段 仍 套 授 权 规 则 。 下 面 
是 一 个 定义 在 testing 名 称 空间 中 的 Role 对 象 的 配置 清单 示例 ， 它 设 定 了 
读 取 、 列 出 及 监视 Pod 和 Service 资 源 的 许可 权限 : 








kind: Role 
apiVersion: rbac.authorization.k8s.io/vi 
metadata: 

namespace: testing 

name: pods-reader 


rules: 
- apiGroups: [""]  #"" 表示 core API group 
resources: ["pods", "pods/10g"] 


verbs: ["get", "list", "watch"] 





类 似 上 面 的 Role 对 象 中 的 rules 也 称 为 PolicyRule， 用 于 定义 策略 规 
则 ， 不 过 它 不 包含 规则 应 用 的 目标 ， 其 可 以 内 舱 的 字段 包含 如 下 几 个 。 


1) apiGroups<[]string>: 包含 了 资源 的 API 组 的 名 称 ， 文 持 列 表格 
式 指定 的 多 个 组 ， 空 串 ("") 表示 核心 组 。 


2) resourceNames<[]string>: 规则 应 用 的 目标 资源 名 称 列表 ， 可 
选 ， 缺 省 时 意味 着 指定 资源 类 型 下 的 所 有 资源 。 


3) resources<[]string>: 规则 应 用 的 目标 资源 类 型 组 成 的 列表 ， 例 
如 pods、deployments、daemonsets、roles 等 ，ResourceAll 表 示 所 有 资 


4) verbs<[]string>: 可 应 用 至 此 规则 匹配 到 的 所 有 资源 类 型 的 操作 
列表 ， 可 用 选项 有 get、list、create、update、patch、watch、proxy、 
redirect、delete 和 deletecollection; 此 为 必 选 字段 。 




















5) nonResourceURLs<[]string>: 用 于 定义 用 户 应 该 有 权限 访问 的 网 
址 列表 ， 它 并 非 名 称 空间 级 别 的 资源 ， 因 此 只 能 应 用 于 ClusterRole 和 
ClusterRoleBinding， 在 Role 中 提供 此 字段 的 目的 仅 为 与 ClusterRole 在 格 
式 上 兼容 。 


绝 大 多 数 资 源 均 可 通过 其 资源 类 型 的 名 称 引 用 ， 
如 “pods” 或 “services” 等 ， 这 些 名 字 与 它们 在 API endpoint 中 的 形式 相 
同 。 不 过 ， 有 些 资 源 类 型 还 文 持 子 资源 〈subresource) ， 例 如 Pod 对 象 
的 /log，Node 对 象 的 /status 等 ， 它 们 的 URL 格 式 通 常 形 如 如 下 表示 : 








GET /api/vi/namespaces/{namespace}/pods/{name}/1lo0og 





在 RBAC 和 角色 定义 中 ， 如 果 要 引用 这 种 类 型 的 子 资源 ， 则 需要 使 
用 “resource/subre-source“ 的 格式 ， 如 上 面 示例 规则 中 的 “pods/log”。 男 
外 ， 还 可 以 通过 直接 给 定 资源 名 称 (resourceName) 来 引用 特定 的 资 
源 ， 此 时 支持 使 用 的 操作 通常 仅 为 get、delete、update 和 patch， 也 可 使 
用 这 四 个 操作 的 子 集 实现 更 小 范围 的 可 用 操作 限制 。 


除了 编写 配置 清单 创建 Role 资 源 之 外 ， 还 可 以 直接 使 用 “kubectl 
create role” 命 令 进行 快速 创建 ， 例 如 ， 下 面 的 命令 在 testing 名 称 空间 中 
创建 了 一 个 名 为 services-admin 的 角色 : 





~]$ kubectl create role services-admin --verb="*" --resource="services,servic 
es/*" -n testing 








将 清单 中 的 Role 资源 也 创建 于 集群 上 之 后 ，testing 名 称 空 间 中 就 有 
了 pods-reader 和 services-admin 两 个 角色 ， 但 角色 本 身 并 不 能 作为 动作 的 
执行 主体 ， 它 们 需要 “ 绑 定 ”(Role-Binding) 到 主体 〈 如 user、group 或 
service account) 之 上 才能 发 生 作 用 。 


RoleBinding 用 于 将 Role 中 定义 的 权限 赋予 一 个 或 一 组 用 户 ， 它 由 一 
组 主体 ， 以 及 一 个 要 引用 来 赋予 这 组 主体 的 Role 或 ClusterRole 组 成 。 需 
要 注意 的 是 ，RoleBinding 仅 能 够 引用 同一 名 称 空 间 中 的 Role 对 象 完成 授 
权 ， 例 如 ， 下 面 配 置 清单 中 的 RoleBinding 于 testing 名 称 空间 中 将 pods- 
reader 角 色 赋 给 了 用 户 kube-user1， 从 而 使 得 kube-userl 拥 了 此 角色 之 上 
的 所 有 许可 授权 : 





kind: RoleBinding 
apiVersion: rbac.authorization.k8s.io/vi 
metadata: 
name: resources-reader 
namespace: testing 
subjects: 


- kind: User 

name: kube-user1 

apiGroup: rbac.authorization.k8s.io 
roleRef: 

kind: Role 

name: pods-reader 

apiGroup: rbac.authorization.k8s.io 





将 此 RoleBinding 资 源 应 用 到 集群 中 ，kube-userl 用 户 便 有 了 读 取 
testing 名 称 空间 中 pods 资 源 的 权限 。 将 kubectl 的 配置 上 下 文 切换 至 kube- 
userl 用 户 ， 分 别 对 pods 和 services 资 源 发 起 访问 请 求 测 试 ， 由 下 面 的 命 
令 结果 可 以 看 出 ， 它 能 够 请 求 读 取 pods 资 源 ， 但 对 其 他 任何 资源 的 任何 
操作 请 求 都 将 被 拒绝 : 





~]$ kubect1 config use-context kube-user1i@kubernetes 

Switched to context "kube-user1i@kubernetes". 

~]$ kubectl get pods -n testing 

No resources found. 

~]$ kubectl1 get services -n testing 

Error from server (Forbidden): services is forbidden: User "kube-useri1" cannot 
list services jin the namespace "testing" 





RoleBinding 资 源 也 能 够 直接 在 命令 行 中 创建 。 例 如 ， 将 kubectl 的 上 
下 文 切换 为 kubernetes-admin 用 户 ， 将 前 面 创建 的 services-admin 和 角色 绑 
定 于 kube-userl 之 上 ， 可 以 使 用 如 下 命令 进行 : 





~]$ kubectl1 config use-context kubernetes-admin@kubernetes 

~]$ kubectl1 create rolebinding admin-services --role=services-admin --user=kube- 
USser1 -n testing 

rolebinding.rbac.authorization.k8s.io "admin-services" created 





再 次 切换 到 kube-user1 用 户 ， 进 行 services 资 源 的 访问 测试 ， 由 下 面 
的 命令 结果 可 知 ， 它 能 够 访问 services 资 源 ， 而 不 再 是 拒绝 权限 : 








~]$ kubect1 config use-context kube-user1i@kubernetes 
~]$ kubectl1 get services -n testing 
No resources found. 





事实 上 ， 通 过 admin-services 这 个 RoleBinding 绑 定 至 services-admin 
角色 之 后 ，kube-user1 用 户 拥有 管理 testing 名 称 空间 中 的 Service 资 源 的 所 
有 权限 。 另 外 需要 注意 的 是 ， 虽 然 RoleBinding 不 能 路 名 称 空 间 引 用 Role 








资源 ， 但 主体 中 的 用 户 账 写 、 用 户 组 和 服务 账号 却 不 受 名 称 空间 的 限 
制 ， 因 此 ， 管 理 员 可 为 一 个 主体 通过 不 同 的 RoleBinding 资 源 绑 定 多 个 名 
称 空间 中 的 角色 。 


RoleBinding 的 配置 中 主要 包含 两 个 散 套 的 字段 subjects 和 roleRef， 
其 中 ，subjects 的 值 是 一 个 对 象 列 表 ， 用 于 给 出 要 绑 定 的 主体 ， 而 
roleRef 的 值 是 单个 对 象 ， 用 于 指定 要 绑 定 的 Role 或 ClusterRole 资 源 。 
subjects 字 上段 的 可 网 套 字 段 具体 如 下 。 


"apiGroup<string> : 要 引用 的 主体 所 属 的 API 群 组 ， 对 于 
ServiceAccount 类 的 主体 来 说 默认 为 "， 而 User 和 Group 类 主体 的 默认 值 
为 "rbac.authorization.k8s.io"。 


kind<string> : 要 引用 的 资源 对 象 〈 主 体 ) 所属 的 类 别 ， 可 用 值 
为 "User""Group" 和 "ServiceAccount" 三 个 ， 必 选 字段 。 


name<string> : 引用 的 主体 的 名 称 ， 必 选 字 段 。 


namespace<string> : 引用 的 主体 所 属 的 名 称 空间 ， 对 于 非 名 称 空 
间 类 型 的 主体 ， 如 "User" 和 "Group"， 其 值 必须 为 衬 ， 人 否则 授权 插件 将 返 
回 错误 信息 。 


roleRef 的 可 和 藤 套 字段 具体 如 下 。 


.apiGroup<string> : 引用 的 资源 〈Role 或 ClusterRole) 所 属 的 API 群 
组 ， 必 选 字段 。 


kind<string> : 引用 的 资源 所 属 的 类 别 ， 可 用 值 为 Role 或 
ClusterRole， 必 选 字 段 。 


.name<string> : 引用 的 资源 的 名 称 。 


Role 和 RoleBinding 是 名 称 空 间 级 别 的 资源 ， 它 们 仅 能 用 于 完成 单个 
名 称 空 间 内 的 访问 控制 ， 此 时 知 要 赋予 某 主 体 多 个 名 称 空 间 中 的 访问 权 
限 ， 就 不 得 不 逐个 名 称 空 间 地 进行 。 另 外 还 有 一 些 资源 其 本 身 并 不 属于 
名 称 空间 (如 PersistentVolume、NameSpace 和 Node 等 ) ， 甚 至 还 有 一 些 
非 资源 型 的 UREL 路 径 〈 如 mhealthz 等 ) ， 对 此 类 资源 的 管理 显然 无 法 在 名 
称 空间 级 别 完 成 ， 此 时 就 需要 用 到 另外 两 个 集群 级 别 的 资源 类 型 


























ClusterRole 和 ClusterRoleBinding。 


10.4.3 ClusterRole 和 ClusterRoleBinding 


集群 级 别 的 角色 资源 ClusterRole 资 源 除 了 能 够 管理 与 Role 资源 一 样 
的 许可 权限 之 外 ， 还 可 以 用 于 集群 级 组 件 的 授权 ， 配 置 方式 及 其 在 rules 
字段 中 可 内 舰 的 字段 也 与 Role 资源 类 似 。 下 面 的 配置 清单 示例 中 定义 了 
ClusterRole 资 源 nodes-reader， 它 拥有 访问 集群 的 节点 信息 的 权限 : 





kind: ClusterRole 
apiVersion: rbac.authorization.k8s.io/vi 
metadata: 
name: nodes-reader 
rules: 
- apiGroups: [""] 
resources: ["nodes"] 
verbs: ["get", "watch", "list"] 








ClusterRole 是 集群 级 别 的 资源 ， 它 不 属于 名 称 空 间 ， 故 在 此 处 其 配 
置 不 应 该 使 用 metadata.namespace 字 段 ， 这 也 可 以 通过 获取 nodes-reader 
的 状态 信息 来 进行 验证 。kube-user1 用 户 此 前 绑 定 的 pods-reader 和 
services-admin 角 色 属 于 名 称 空间 ， 它 们 无 法 给 予 此 用 户 访 问 集群 级 别 
nodes 资 源 的 权限 。 


RoleBinding 也 能 够 将 主体 绑 定 至 ClusterRole 资 源 之 上 ， 但 仅 能 赋予 
用 户 访 问 Role-Binding 资 源 本 身 所 在 的 名 称 空间 之 内 可 由 ClusterRole 赋 
予 的 权限 ， 例 如 ， 在 ClusterRole 具 有 访问 所 有 名 称 空 间 的 ConfigMap 资 
源 权 限时 ， 通 过 testing 名 称 空间 的 RoleBinding 将 其 绑 定 至 kube-user1 用 
户 ， 则 kube-user1 用 户 就 具有 了 访问 testing 名 称 空间 中 的 ConfigMap 资 源 
的 权限 ， 但 不 能 访问 其 他 名 称 空 间 中 的 ConfigMap 资 源 。 不 过 ， 知 借助 
ClusterRoleBinding 进 行 绑 定 ， 则 kube-user1 就 具有 了 上 所 有 相关 名 称 空间 
中 的 资源 的 访问 权限 ， 如 图 10-12 所 示 。 
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图 10-12 RoleBinding 与 ClusterRoleBinding 


因此 ， 一 种 常见 的 做 法 是 集群 管理 员 在 集群 范围 内 预先 定义 好 一 组 
访问 名 称 空间 级 别 资源 权限 的 ClusterRole 资 源 ， 而 后 在 多 个 名 称 空间 中 
多 次 通过 RoleBinding 引 用 它们 ， 从 而 让 用 户 分 别 具 有 不 同名 称 空间 上 的 
资源 的 相应 访问 权限 ， 完 成 名 称 空 间 级 别 权限 的 快速 授予 。 当 然 ， 如 果 
通过 ClusterRoleBinding 引 用 这 类 的 ClusterRole， 则 相应 的 用 户 即 拥有 了 
在 所 有 相关 名 称 空 间 上 的 权限 。 


集群 级 别 的 资源 nodes、persistentvolumes 等 资源 ， 以 及 非 资源 型 的 
URL 不 属于 名 称 空 间 级 别 ， 故 此 通过 RoleBinding 绑 定 人 至 用 户 时 无 法 完成 
访问 授权 。 事 实 上 ， 上 所 有 的 非 名 称 空 间 级 别 的 资源 都 无 法 通过 
RoleBinding 绑 定 至 用 户 并 赋予 用 户 相 关 的 权限 ， 这 些 是 属于 
ClusterRoleBinding 的 功能 。 


另外 ， 除 了 名 称 空间 及 集群 级 别 的 资源 之 外 ，Kubernetes 还 有 
着 /api、/apis、/healthz、/swaggerapi 和 /version 等 非 资源 型 URL， 对 这 些 
URL 的 访问 也 必须 事先 获得 相关 的 权限 。 同 集群 级 别 的 资源 一 样 ， 它 们 
也 只 能 定义 在 ClusterRole 中 ， 且 需要 基于 ClusterRoleBinding 进 行 授权 。 











不 过 ， 对 此 类 资源 的 读 取 权限 已 经 由 系统 默认 的 名 称 同 为 system: 
discovery 的 ClusterRole 和 ClusterRoleBinding 两 个 资源 自动 设 定 。 下 面 的 
命令 显示 了 system: discovery ClusterRole 的 相关 信息 : 





~]$ kubectl1 get clusterrole system:discovery -0 yaml 
apiVersion: rbac.authorization.k8s.io/vi 
kind: ClusterRole 
metadata: 
name: system:discovery 


rules: 

- nonResourceURLs: 
- /api 
- /api/* 
- /apis 
- /apis/* 
- /healthz 
- /swagger-2.0.0.pb-vi 
- /swagger .json 
- /swaggerapi 
- /swaggerapi/* 
- /version 
verbs: 
- get 





nonResourceURLs 字 上 段 给 出 了 相关 的 URL 列 表 (不 同 版 本 的 
Kubernetes 系 统 上 的 显示 可 能 略 有 区 别 ) ， 人 允许 的 访问 权限 仪 有 “get” 一 
个 。 引 用 了 此 资源 的 ClusterRoleBinding 的 相关 信息 如 下 面 的 命令 及 其 结 
果 所 示 : 





~]$ kubect1 get clusterrolebindings system:discovery -0 yaml 
apiVersion: rbac.authorization.k8s.io/vi 
kind: ClusterRoleBinding 
metadata: 
name: system:discovery 


roleRef: 
apiGroup: rbac.authorization.k8s.io 
kind: ClusterRole 
name: system:discovery 


subjects: 
- apiGroup: rbac.authorization.k8s.io 
kind: Group 


name: system:authenticated 

- apiGroup: rbac.authorization.k8s.io 
kind: Group 
name: system:unauthenticated 





由 命令 的 输出 结果 可 知 ， 它 绑 定 了 system: authenticated 和 system: 


unauthencated 两 个 组 ， 这 守 括 了 所 有 的 用 户 账 号 ， 因 此 所 有 用 户 默 认 均 
有 权限 请 求 读 取 这 些 资源 ， 任 何 发 往 API Server 的 此 类 端点 读 取 请 求 都 
会 得 到 响应 。 定 义 其 他 类 型 的 访问 权限 ， 其 方法 可 参照 system: 
discovery 这 个 ClusterRole 资 源 进行 。 例 如 ， 下 面 的 ClusterRole 资 源 示例 
定义 了 对 非 资 源 型 URL 路 径 /healthz 的 读 写 访问 权限 : 











apiVersion: rbac.authorization.k8s.io/vi 
kind: ClusterRole 
metadata: 
name: healthz-admin 
rules: 
- NonResourceURLs: 
- /healthz 
verbs: 
- get 
- create 





男 外 ， 非 资源 型 URL 的 授权 规则 与 资源 权限 的 授权 规则 可 定义 在 同 
一 个 ClusterRole 中 ， 它 们 同属 于 rules 字 段 中 的 对 象 。 


10.4.4 ”聚合 型 ClusterRole 


Kubernetes 自 1.9 版 本 开始 支持 在 rules 字 上 段 中 舱 套 aggregationRule 字 
段 来 整合 其 他 的 ClusterRole 对 象 的 规则 ， 这 种 类 型 的 ClusterRole 的 权限 
受 控 于 控制 占 ， 它 们 由 所 有 被 标签 选择 器 匹配 到 的 用 于 聚合 的 
ClusterRole 的 授权 规则 合并 生成 。 下 面 是 一 个 示例 ， 它 定义 了 一 个 标签 
选择 器 用 于 挑选 岂 配 的 ClusterRole: 








kind: ClusterRole 
apiVersion: rbac.authorization.k8s.io/vi 
metadata: 
name: monitoring 
aggregationRule: 
clusterRoleSelectors: 
- matchLabels: 
rbac.example.com/aggregate-to-monitoring: "true" 
rules: [] 





任何 能 够 被 示例 中 的 资源 的 标签 选择 右 罗 配 到 的 ClusterRole 的 相关 
规则 都 将 一 同 合并 为 它 的 授权 规则 ， 后 续 新 增 的 ClusterRole 资 源 亦 是 如 
此 。 因 此 ， 聚 合 型 ClusterRole 的 规则 会 随 独 标签 选择 器 的 匹配 结果 而 动 
态 变化 。 下 面 即 是 一 个 能 匹配 到 此 聚合 型 ClusterRole 的 另 一 个 
ClusterRole 的 示例 : 





kind: ClusterRole 
apiVersion: rbac.authorization.k8s.io/vi 
metadata: 

name: monitoring-endpoints 

labels: 

rbac.example.com/aggregate-to-monitoring: "true" 

# These rules will be added to the "monitoring" role. 
rules: 
- apiGroups: [""] 

Resources: ["services", "endpoints", "pods"] 

verbs: ["get", "list", "watch"] 





创建 这 两 个 资源 ， 而 后 得 看 聚合 型 ClusterRole 资 源 monitoring 的 相 
关 权 限 信息 ， 由 下 面 的 命令 结果 可 知 ， 它 所 拥有 的 权限 包含 了 
ClusterRole 资 源 monitoring-endpoints 的 所 有 授权 : 





~]$ kubectl create -f monitoring.yaml -f monitoring-endpoints.yaml 


~]$ kubectl1 get clusterrole monitoring -0 yaml 
aggregationRule: 

clusterRoleSelectors: 

- matchLabels: 

rbac.example.com/aggregate-to-monitoring: "true" 

apiVersion: rbac.authorization.k8s.io/vi 
kind: ClusterRole 
metadata: 

name: monitoring 


rules: 
- apiGroups: 
TITT 

resources: 
- Services 
- endpoints 
- pods 
verbs: 
- get 
- Jist 
- watch 





事实 上 ，Kubernetes 系 统 上 面 同 用 户 的 内 建 ClusterRole admin 和 edit 
也 是 聚合 型 Cluster-Role， 因 为 这 可 以 使 得 默认 角色 中 包含 自 定 义 资源 的 
相关 规则 ， 例 如 ， 由 CustomResource-Definitions 或 Aggregated API 服 务 器 
提供 的 规则 等 。 


10.4.5 面 回 用 户 的 内 建 ClusterRole 


API Server 内 建 了 一 组 默认 的 ClusterRole 和 ClusterRoleBinding 以 预 
留 系 统 使 用 ， 其 中 大 多 数 都 以 “system: ”为 前 级 。 男 外 还 有 一 些 非 
以 “system: ”为 前 级 的 默认 的 Role 资 源 ， 它 们 是 为 面向 用 户 的 需求 而 设 
计 的 ， 包 括 超级 用 户 角 色 (cluster-admin) 、 用 于 授权 集群 级 别 权限 的 
ClusterRoleBinding (cluster-status〉 以 及 授予 特定 名 称 空间 级 别 权 限 的 
RoleBinding (admin、edit 和 view) ， 如 图 10-13 所 示 。 竺 握 这 些 默 认 的 
内 建 ClusterRole 对 后 期 按 需 创建 用 户 并 快速 配置 权限 至 关 重 要 。 
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图 10-13 ”内 建 的 面 问 用户 的 ClusterRole 


内 建 的 ClusterRole 资 源 cluster-admin 拥 有 管理 集群 所 有 资源 的 权 
限 ， 它 基于 同名 的 ClusterRoleBinding 资 源 绑 定 到 了 “system: masters” 组 
上 ， 这 意味 着 所 有 隶属 于 此 组 的 用 户 都 将 具有 集群 的 超级 管理 权限 。 
kubeadm 安 装 设 定 集群 时 自动 创建 的 配置 文件 /etckubernetes/admin.conf 
中 定义 的 用 户 kubernetes-admin 使 用 证 书 文件 /etc/kubernetes/pki/piserver- 
kubelet-client.crt| 引 API Server 进 行 验证 。 而 此 证 书 的 Subject 信 息 
为 “/O=system: masters/CN=kubernetes-admin”， 进 行 认 证 时 ，CN 的 值 可 
作为 用 户 名 使 用 ， 而 O 的 值 将 作为 用 户 所 属 组 名 使 用 ， 因 此 ， 
kubernetes-admin 具 有 集群 管理 权限 。 


于 是 ， 为 Kubernetes 集 群 额外 自 定 义 超 级 管理 员 的 方法 至 少 具 有 两 
种 : 一 种 是 创建 用 户 证 书 ， 其 Subject 中 O 的 值 为 “system: masters”， 另 





一 种 是 创建 ClusterRoleBinding 将 用 户 绑 定 至 cluster-admin 之 上 。 其 具体 
的 实现 方法 均 可 参照 10.4.4 节 和 本 节 中 的 内 容 略 加 变通 而 实现 ，cluster- 
status 的 使 用 方法 与 此 类 同 ， 有 所 区 别 的 仪 在 于 权限 本 号 。 


另外 ， 在 多 租户 、 多 项 目 或 多 环境 等 使 用 场景 中 ， 用 户 通 党 应 该 获 
取 名 称 空 间 级 别 绝 大 多 数 资源 的 管理 、 只 读 或 编辑 权限 ， 这 类 权限 的 快 
速 授 予 可 通过 在 指定 的 名 称 空间 中 创建 RoleBinding 资 源 引 用 内 建 的 
ClusterRole 资 源 admin、view 或 edit 来 进行 。 例 如 ， 在 名 称 空间 dev 中 创建 
一 个 RoleBinding 资 源 ， 它 将 引用 admin， 并 绑 定 至 kube-user1， 使 得 此 用 
ee 
源 的 权限 : 





























~]$ kubectl create rolebinding dev-admin --clusterrole=admin --user=kube-user1 -n de 








而 后 切换 至 kube-user1 用 户 在 dev 中 创建 一 个 资源 ， 并 查看 相关 的 信 
居 进 行 访问 测试 ， 如 下 面 的 命令 所 示 : 








~]$ kubectl1 create deployment myapp-deploy --image=ikubernetes/myapp:vi -n dev 
deployment .extensions "myapp-deploy" created 
~]$ kubectl get all -n dev 











如 果 需 要 授予 的 是 编辑 或 只 读 权 限 ， 则 仅 需 要 将 创建 RoleBinding 时 
引用 的 ClusterRole 相 应 地 修改 为 edit 或 view 即 可 。 表 10-1 总 结 了 典型 的 面 
向 用 户 的 内 建 ClusterRole 及 其 功用 。 


表 10-1 面 癌 用 户 的 内 建 ClusterRole 资 源 
i 有 


cluster-admin system:masters 组 授予 超级 管理 员 在 任何 对 象 上 执行 任何 操作 的 权限 


以 RoleBinding 机 制 访 问 指定 名 称 空间 的 所 有 资源 ， 包 括 名 称 
admin None 要 A 大 
空间 的 Role 和 RoleBinding， 但 不 包括 资源 配置 和 名 称 空间 本 身 
允许 读 写 访问 一 个 名 称 空间 内 的 绝 大 多 数 资源 ， 但 不 允许 查 
edit None ea 5 
看 或 修改 Role 或 RoleBinding 
允许 读 取 一 个 名 称 空间 内 的 绝 大 多 数 资 源 ， 但 不 允许 查看 
VieW None Re i DS 
Role 或 RoleBinding， 以 及 secret 资源 





10.4.6 ”其 他 的 内 建 ClusterRole 和 ClusterRoleBinding 


API Server 会 创建 一 组 默认 的 ClusterRole 和 ClusterRoleBinding， 大 
多 数 都 以 “system: ”为 前 级 ， 被 系统 基础 架构 所 使 用 ， 修 改 这 些 资源 将 
会 导致 集群 功能 不 正常 。 例 如 ， 如 果 修 改 了 为 kubelet 赋 权 的 “system: 
node” 这 一 ClusterRole， 则 将 会 导致 kubelet 无 法 工作 。 所 有 默认 的 
ClusterRole 和 ClusterRoleBinding 都 打 了 标 
签 “kubernetes.io/bootstrapping=rbac-defaults”。 


每 次 启动 时 ，API Server 都 会 自动 为 默认 的 ClusterRole 重 新 赋予 缺 
失 的 权限 ， 以 及 为 默认 的 ClusterRoleBinding 绑 定 缺 失 的 Subject。 这 种 机 
制 给 了 集群 从 意外 修改 中 自动 恢复 的 能 力 ， 以 及 升级 版 本 后 ， 目 动 将 
ClusterRole 和 ClusterRoleBinding 升 级 到 满足 新 版 本 需求 的 能 





@ 提示 “必要 时 ， 在 默认 的 ClusterRole 或 ClusterRoleBinding 上 
设置 annnotation 中 “rbac.authorization.kubernetes.io/autoupdate“ 属 性 的 值 


为 “false” 即 可 禁止 此 种 自动 恢复 功能 。 


Kubernetes 内 建 的 其 他 ClusterRole 和 ClusterRoleBinding 还 有 很 多 ， 
它们 绝 大 多 数 都 是 用 于 系统 本 身 的 诸多 组 件 结合 RBAC 获 得 最 小 化 但 完 
整 的 资源 访问 授权 。 它 们 大 体 可 分 为 专用 于 核心 的 组 件 、 附 加 的 组 件 、 
资源 发 现 及 controller-manager 运 行 核 心 控 制 循环 (control loop) 等 几 个 
类 型 ， 如 system: kube-sheduler、system: kube-controller-manager、 
system: node、system: node-proxier 和 system: kube-dns 等 ， 大 多 数 都 可 


以 做 到 见 名 知 义 ， 这 里 不 再 逐一 给 出 说 明 。 


10.5 Kubernetes Dashboard 


Dashboard 是 Kubernetes 的 Web GUI， 可 用 于 在 Kubernetes 集 群 上 部 
署 容 器 化 应 用 、 应 用 排 障 、 管 理 集群 本 和 映 及 其 附加 的 资源 等 。 它 常 被 管 
理 员 用 于 集群 及 应 用 速 览 、 创 建 或 修改 单个 资源 《如 Deployments、Jobs 
和 DaemonSets 等 ) ， 以 及 扩展 Deployment、 启 动 深 动 更 新 、 重 启 Pod 或 
使 用 部 署 问 导 部 署 一 个 新 应 用 等 。 


[2 
© 注意 ” Dashboard 依赖 于 Heapster 或 Metrics Server 完 成 指标 数 
据 的 采集 和 可 视 化 。 


Dashboard 的 认证 和 授权 均 可 由 Kubernetes 集 群 实 现 ， 它 自身 仅 是 一 
个 代理 ， 所 有 的 相关 操作 都 将 发 给 API Server 进 行 ， 而 非 由 Dashboard 自 
行 完 成 。 目 前 它 支 持 使 用 的 认证 方式 有 承载 令 脾 (bear token) 和 
kubeconfig 两 种 ， 在 访问 之 前 需要 准备 好 相应 的 认证 凭证 。 


10.5.1 ， 部署 HTTPS 通 信 的 Dashboard 


Dashboard 1.7〈 不 含 ) 之 前 的 版 本 在 部 晋 时 直接 赋予 了 管理 权限 ， 
这 种 方式 可 能 存在 安全 风险 ， 因 此 ，1.7 及 之 后 的 版 本 默认 在 部 署 时 仅 
定义 了 运行 Dashboard 所 需要 的 最 小 权限 ， 仅 能 够 在 Master 主 机 上 通 
过 “kubectl proxy” 命 令 创 建 代理 后 于 本 机 进行 访问 ， 它 默认 禁止 了 来 自 
于 其 他 任何 主机 的 访问 请 求 。 知 要 绕 过 “kubectl proxy” 和 直接 访问 
Dashboard， 则 需要 在 部 晋 时 提供 证 书 以 便 与 客户 端 进行 通信 时 建立 一 
个 安全 的 HTTPS 连 接 。 证 书 既 可 由 公信 CA 颁发 ， 也 可 目 行 使 用 openssl 
或 cfssl 一 类 的 工具 来 创建 。 


部 署 Dashboard 时 会 从 Secrets 对 象 中 加 载 所 需要 的 私 钥 和 证 书 文 
件 ， 需 要 事先 准备 好 相关 的 私 钥 、 证 书 和 Secrets 对 象 。 需 要 注意 的 是 ， 
下 面 的 命令 需要 以 管理 员 的 身份 在 Master 节 点 上 运行 ， 否 则 将 无 法 访问 
到 ca.key 文 件 : 











~]# (umask 077; openssl genrsa -out dashboard,key 2048 ) 
~]# openssl req -new -key dashboard.key -out dashboard.csr -subj "/0=iLinux/CN=dasht 
~]# openssl x509 -req -in dashboard.csr -CA /etc/kubernetes/pki/ca.crt \ 

-CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out dashboard,.crt -days 365( 








接 下 来 ， 基 于 生成 的 私 钥 和 证 书 文件 创建 名 为 kubernetes-dashboard- 
certs 的 Opaque 类 型 的 Secret 对 象 ， 其 键 名 分 别 为 dashboard.key 和 
dashboard.crt: 





~]$ kubect1l create secret generic kubernetes-dashboard-certs \ 
-n kube-system --from-file=dashboard.crt=./dashboard.crt \ 
--from-file=dashboard.key=./dashboard.key -n kube-system 





Secret 对 象 准备 完成 后 即 可 部 团 Dashboard。 若 无 其 他 自 定义 部 署 的 
需要 ， 可 直接 基于 在 线 资源 配置 清单 。 不 过 ， 资 源 清单 中 也 创建 了 
Secrets 对 象 ， 因 此 ， 它 可 能 会 发 出 警告 信息 。 男 外 ， 默 认 创 建 的 Service 
对 象 类 型 为 ClusterIP， 它 仅 能 在 Pod 客 户 端 中 访问 ， 知 需 在 集群 外 通过 
浏览 器 访问 Dashboard， 则 需要 修改 其 类 型 为 NodePort 再 进行 创建 ， 或 者 
在 创建 后 通过 修改 命令 进行 设 定 。 这 里 采取 直接 在 线 创建 ， 并 修改 其 
Service 对 象 kubernetes-dashboard 的 类 型 的 方式 : 




















~]$ kubect1 apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/ 
src/deploy/recommended/kubernetes-dashboard.yaml 

~]$ kubectl1 patch svc kubernetes-dashboard -p '{"spec":{"type":"NodePort"}}' -n 
kube-system 





确认 其 使 用 的 NodePort 之 后 便 可 在 集群 外 通过 浏览 器 进行 访问 : 





~]$ kubectl1 get svc kubernetes-dashboard -n kube-system 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
kubernetes-dashboard NodePort 10.110.145.88 <none> 443:31999/TCP 2h 





图 10-14 即 为 其 默认 显示 的 登录 页 面 ， 文 持 的 认证 方式 为 kubeconfig 
和 token《〈 令 牌 ) 两 种 。 


€ C | A 不 安全 | https://172.16.0.67:31999/#!/login 


Kubernetes 仪表 板 


© Kubeconfig 


请 选择 您 已 配置 用 来 访问 集群 的 kubeconfig 文件 ， 请 浏览 配置 对 多 个 集 
群 的 访问 一 节 ， 了 解 更 多 关于 如 何 配置 和 使 用 kubeconfig 文件 的 信息 


〇 令 牌 


每 个 服务 账号 都 有 一 条 保密 字典 保存 持 有 者 令 牌 ， 用 来 在 仪表 板 登录 ,请 
浏览 验证 一 节 ， 了 解 更 多 关于 如 何 配置 和 使 用 持 有 者 令 牌 的 信息 








图 10-14 Dashboard 认 证 界面 


Dashboard 是 运行 于 Pod 对 象 中 的 应 用 ， 其 连接 API Server 的 账户 应 
为 ServiceAccount 类 型 ， 因 此 ， 用 户 在 登录 界面 提供 的 用 户 账号 须 得 是 
此 类 账户 ， 而 且 访 问 权 限 也 取决 于 kubeconfig 或 token 认 证 时 的 
ServiceAccount 用 户 的 权限 。ServiceAccount 的 集群 资源 访问 权限 取决 于 
它 绑 定 的 角色 或 集群 角色 ， 例 如 ， 为 登录 的 用 户 授 权 集 群 级 别 的 管理 权 
限时 可 直接 绑 定 内 建 的 集群 角色 cluster-admin， 授 权 名 称 空 间 级 别 的 管 
理 权 限时 ， 可 直接 绑 定 内 建 的 集群 角色 admin。 当 然 ， 也 可 以 直接 上 自 定 
义 RBAC 的 角色 或 集群 角色 ， 并 进行 绑 定 授权 ， 例 如 集群 级 别 的 只 读 权 
限 或 名 称 空间 的 只 读 权 限 。 














10.5.2 ”配置 token 认 证 


集群 级 别 的 管理 操作 依赖 于 集群 管理 员 权限 ， 例 如 ， 管 理 持久 存储 
卷 和 名 称 空间 等 资源 ， 内 建 的 cluster-admin 和 集群 角色 拥有 相关 的 全 部 权 
限 ， 创 建 ServiceAccount 并 将 其 绑 定 其 上 即 可 完成 集群 管理 员 授 权 。 而 
用 户 通 过 相应 的 ServiceAccount 的 token 信 息 完 成 Dashboard 认 证 也 就 能 扮 
演 起 Dashboard 接 口上 的 集群 管理 员 和 角色 。 人 例如， 下面 创建 一 个 名 为 
dashboard-admin 的 ServiceAccount， 并 完成 集群 角色 绑 定 : 





~]$ kubect1 create Serviceaccount dashboard-admin -n kube-system 
~]$ kubect1l create clusterrolebinding dashboard-admin --clusterrole=cluster-admin \ 
--Serviceaccount=kube-system:dashboard-admin 





创建 ServiceAccount 对 象 时 ， 它 会 目 动 为 用 户 生 成 用 于 认证 的 token 
信息 ， 这 一 点 可 以 从 与 其 相关 的 Secrets 对 象 上 获取 : 





~]$ ADMIN_SECRET=$(kubect] -n kube-system get secret | awk '/^dashboard-admin/{print 
~]$ kubect1 describe secrets $ADMIN SECRET -n kube-system kube-system 


Name : dashboard-admin-token-jfcd6 
Namespace: kube-system 
token: eyJhbGci0iJSUzI1NiIsImtpZCI6IiJ9.eyJpc3Mi0iJrdwJlcm5ld6VzL3N1lcnz 


pY2VhY2NvdwW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2awNlYWNjb3VudC9uYW1lc3BhY2Ui0iJrd 
WJ1LXNS5c3R1bSIsImt1iYmVyb...... 





对 上 面 获 取 到 的 token 在 登录 界面 选择 令 牌 认证 方式 ， 并 键入 token 
令 牌 即 要 登录 的 Dashboard， 其 效果 如 图 10-15 所 示 。 


上 面 认 证 时 用 到 的 令 牌 将 采用 base64 的 编码 格式 ， 且 登录 时 需要 将 
原 内 容 贴 入 文本 框 ， 存 储 及 操作 都 有 其 不 便 之 处 ， 建 议 用 户 将 它 存 入 
kubeconfig 配 置 文件 中 ， 通 过 kubeconfig 的 认证 方式 进行 登录 。 





10.5.3 ”配置 kubeconfig 认 证 


kubeconfig 是 认证 信息 承载 工具 ， 它 能 够 存 入 私 钥 和 证 书 ， 或 者 认 
证 令 牌 等 作为 用 户 的 认证 配置 文件 。 为 了 说 明 如 何 配置 一 个 仅 具 有 特定 
名 称 空 间 管理 权限 的 登录 账号 ， 这 里 再 次 创建 一 个 新 的 ServiceAccount 
用 于 管理 默认 的 default 名 称 空间 ， 并 将 之 绑 定 于 admin 和 集群 角色 ， 其 操 
作 过 程 与 10.5.2 节 的 方式 相似 : 








~]$ kubect1l create serviceaccount def-ns-admin -n default 
~]$ kubect1l create rolebinding def-ns-admin --clusterrole=admin \ 
--Serviceaccount=default:def-ns-admin 


€ C | A 不 安全 | https//172.16.0.66:31999/#/overview?namespace=kube-system 
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图 10-15 ”Dashboard 主 面板 


下 面 分 步骤 说 明 如 何 创建 所 需 的 kubeconfig 文 件 。 第 一 步 ， 初 始 化 
集群 信息 ， 提 供 API Server 的 URL， 以 及 验证 API Server 证 书 所 用 到 的 
CA 证 舍 。 





~]$ kubectl1 config set-cluster kubernetes --embed-certs=true --server="https:// 
172.16.0.70:6443" \ 
--certificate-authority=/etc/kubernetes/pki/ca.crt --kubeconfig=./def-ns-admin. 


kubeconfig 





第 二 步 ， 获 取 def-ns-admin 的 token， 并 将 其 作为 认证 信息 。 由 于 直 
接 得 到 的 token 为 base64 编 码 格式 ， 因 此 ， 下 面 使 用 了 “base64-d” 命 令 将 
其 解码 还 原 : 





~]$ DEFNS_ADMIN_ SECRET=$(kubectl1 -n default get secret | awk '/^def-ns-admin /{print 
~]$ DEFNS_ADMIN_TOKEN=$(kubectl1 -n default get secret ${DEF_NS ADMIN_ SECRET} 和 
-0 jsonpath={.data.token}|base64 -d) 
~]$ kubectl1 config set-credentials def-ns-admin --token=${DEFNS ADMIN_ TOKEN} \\ 
--kubeconfig=./defns-admin.kubeconfig 





第 三 步 ， 设 置 context 列 表 ， 定 义 一 个 名 为 def-ns-admin 的 context: 





~]$ kubect1 config set-context def-ns-admin --cluster=kubernetes \ 
--User=defns-admin --kubeconfig=./defns-admin.kubeconfig 





最 后 指定 要 使 用 的 context 为 前 面 定义 的 名 为 def-ns-admin 的 


context: 





~]$ kubectl1 config use-context def-ns-admin --kubeconfig=./defns-admin.kubeconfig 





到 此 为 止 ， 一 个 用 于 Dashboard 登 录 认 证 的 default 名 称 空间 的 管理 员 
账号 配置 文件 已经 设置 完成 ， 将 文件 复制 到 远程 客户 并 上 即 可 用 于 登录 
认证 。 


配置 token 认 证 和 kubeconfig 认 证 时 创建 ServiceAccount 和 完成 集群 角 
色 的 绑 定 以 及 角色 绑 定 的 过 程 也 可 以 使 用 资源 配置 清单 文件 来 实现 ， 相 
关 的 文件 可 在 本 章 的 代码 清单 目录 中 获得 ， 分 别 为 dashboard-admin.yaml 
和 def-ns-admin.yaml， 可 用 它们 取代 前 面相 关 的 创建 命令 。 关 于 
Dashboard 的 使 用 这 里 束 不 再 多 做 介绍 了 ， 读 者 根据 界面 提示 信息 很 快 
惑 能 掌握 共用 法 。 





10.6 ” 准 入 控制 右 与 应 用 示例 


在 经 由 认证 插件 和 授权 插件 分 别 完成 身份 认证 和 权限 检查 之 后 ， 准 
入 控制 器 将 拦截 那些 创建 、 更 新 和 删除 相关 的 操作 请 求 以 强制 实现 控制 
器 中 定义 的 功能 ， 包 括 执行 对 象 的 语义 验证 、 设 置 缺失 字段 的 默认 值 、 
限制 所 有 容器 使 用 的 镜像 文件 必须 来 自 某 个 特定 的 Registry、 检 查 Pod 对 
象 的 资源 需求 是 否 超出 了 指定 的 限制 范围 等 。 


但 是 准 入 控制 占 的 相关 代码 必 须要 由 管理 员 编 译 进 kube-apiserver 中 
才能 使 用 ， 实 现 方式 缺乏 灵活 性 。 于 是 ，Kubernetes 自 1.7 版 本 引入 了 
Initializers 和 External Admission Webhooks 来 尝试 突破 此 限制 ， 而 且 自 1.9 
版 本 起 ，External Admission Webhooks 叉 被 分 为 Mutating- 
AdmissionWebhook 和 ValidatingAdmissionWebhook 两 种 类 型 ， 分 别 用 于 
在 API 中 执行 对 象 配 置 的 “变异 ”和 “验证 ”操作 。 在 具体 的 代码 实现 上 ， 
一 个 准 入 控制 器 可 以 是 “验证 ”型 、“ 变 异 ” 型 或 兼 具 此 两 项 功能 。 变 异 控 
制 器 可 以 修改 他 们 许可 的 对 象 ， 而 验证 控制 器 则 一 般 不 会 。 


在 有 基体 运行 时 ， 准 入 控制 可 分 为 两 个 阶段 ， 第 一 个 阶段 串 行 运行 各 
变异 型 控制 器 ， 第 二 个 阶段 串 行 运行 各 验证 型 控制 器 ， 在 此 过 程 中 ， 一 
旦 任 一 阶段 中 的 任何 控制 器 拒绝 请 求 ， 则 立即 拒绝 整个 请 求 ， 并 向 用 户 
返回 错误 。 








10.6.1 ”LimitRange 资 源 与 LimitRanger 准 入 控制 器 


虽然 用 户 可 以 为 容器 指定 资源 需求 及 资源 限制 ， 但 未 予 指定 资源 限 
制 属性 的 容器 应 用 很 有 可 能 因 故 否 挥 所 在 工作 节点 上 的 所 有 可 用 计算 资 
源 ， 因 此 妥当 的 做 法 是 使 用 LimitRange 资 源 在 每 个 名 称 空间 中 为 每 个 容 
器 指定 最 小 及 最 大 计算 资源 用 量 ， 甚 至 是 设置 默认 的 计算 资源 需求 和 计 
算 资 源 限 制 。 在 名 称 空间 上 定义 了 LimitRange 对 象 之 后 ， 客 户 端 提交 创 
建 或 修改 的 资源 对 象 将 受到 LimitRanger 控 制 器 的 检查 ， 任 何 违 反 
LimitRange 对 象 定义 的 资源 最 大 用 量 的 请 求 将 被 直接 拒绝 。 























LimitRange 资 源 支 持 限 制 容器 、Pod 和 PersistentVolumeClaim 三 种 资 
源 对 象 的 系统 资源 用 量 ， 其 中 Pod 和 容器 主要 用 于 定义 可 用 的 CPU 和 内 
存 资源 范围 ， 而 PersistentVolume-Claim 则 主要 定义 存储 空间 的 限制 范 
围 。 下 面 的 配置 清单 以 容器 的 CPU 资 源 为 例 ，default 用 于 定义 默认 的 资 
源 限 制 ，defaultRequest 定 义 默 认 的 资源 需求 ，min 定 义 最 小 的 资源 用 
量 ， 而 最 大 的 资源 用 量 既 可 以 使 用 max 给 出 固定 值 ， 也 可 以 使 用 
maxLimitRequestRatio 设 定 为 最 小 用 量 的 指定 倍数 : 








apiVersion: v1 
kind: LimitRange 
metadata: 
name: cpu-limit-range 
spec: 
limits: 
- default: 
cpu: 1000m 
defaultRequest: 
cpu: 1000m 
min: 
cpu: 500m 
max: 
cpu: 2000m 
maxLimitRequestRatio: 
cpu: 4 
type: Container 





将 配置 清单 中 的 资源 创建 于 集群 上 的 default 名 称 空 间 中 ， 而 后 即 可 
使 用 describe 命 令 查 看 相关 资源 的 生效 结果 。 创 建 不 同 的 Pod 对 象 对 默认 
值 、 最 小 资源 限制 及 最 大 资源 限制 分 别 进行 测试 以 验证 其 限制 机 制 。 


首先 ， 创 建 一 个 仅 包 含 一 个 容器 且 没 有 默认 系统 资源 需求 和 限制 的 











Pod 对 象 : 





~]$ kubectl1 run limit-pod1i--image=ikubernetes/myapp:v1i --restart=Never 





Pod 对 象 limit-pod1 的 详细 信息 中 ， 容 器 状态 信息 段 中 ，CPU 资 源 被 
默认 设 定 为 如 下 配置 ， 这 正好 符合 了 LimitRange 对 象 中 定义 的 默认 值 : 





Limits: 
cpu: 1 

Requests: 
cpu: 1 





若 Pod 对 象 设 定 的 系统 资源 需求 量 小 于 LimitRange 中 的 最 小 用 量 限 
制 ， 则 会 触发 LimitRanger 准 入 控制 器 拒绝 相关 的 请 求 : 





~]$ kubectl1 run limit-pod2 --image=ikubernetes/myapp:vi \ 
--restart=Never --requests='cpu=400m' 

Error from server (Forbidden): pods "limit-pod4" is forbidden: minimum cpu usage 
per Container is 500m, but request is 400m. 











若 Pod 对 象 设 定 的 系统 资源 限制 量 大 于 LimitRange 中 的 最 大 用 量 限 
制 ， 则 一 样 会 触发 LimitRanger 准 入 控制 器 拒绝 相关 的 请 求 : 





~]$ kubectl1 run limit-pod3 --image=ikubernetes/myapp:v1 --restart=Never --limits= 
"Cpu=3000m'' 

Error from server (Forbidden): pods "limit-pod2" is forbidden: maximum cpu 
Usage per Container is 2, but limit is 3. 





事实 上 ， 在 LimitRange 对 象 中 设置 的 默认 的 资源 需求 和 资源 限制 ， 
同 最 小 资源 用 量 及 最 大 资源 用 量 限制 能 够 组 合 出 多 种 不 同 的 情形 ， 不 同 
组 合 场景 下 真正 生效 的 结果 也 会 存在 不 小 的 差异 。 另 外 ， 内 存 资源 及 
PVC 资 源 限制 的 实现 与 CPU 资 源 大 同 小 异 ， 鉴 于 篇 幅 有 限 ， 这 部 分 就 留 
待 读者 自行 验证 了 。 





10.6.2 ”ResourceQuota 资 源 与 准 入 控制 器 


尽管 LimitRange 资 源 能 限制 单个 容器 、Pod 及 PVC 等 相关 计算 资源 
或 存储 资源 的 用 量 ， 但 用 户 依然 可 以 创建 数量 众多 的 此 类 资源 对 象 进 而 
侵占 所 有 的 系统 资源 。 于 是 ，Kubernetes 提 供 了 ResourceQuota 资 源 用 于 
定义 名 称 空间 的 对 象 数 量 或 系统 资源 配额 ， 它 文 持 限 制 每 种 资源 类 型 的 
对 象 总 数 ， 以 及 所 有 对 象 所 能 消耗 的 计算 资源 及 存储 资源 总 量 等 。 
ResourceQuota 准 入 控制 器 负责 观察 传 入 的 请 求 ， 并 确保 它 没 有 违反 相应 
名 称 空间 中 ResourceQuota 对 象 定 义 的 任何 约束 。 


于 是 ， 管 理 员 可 为 每 个 名 称 空间 分 别 创建 一 个 ResourceQuota 对 象 ， 
随后 ， 用 户 在 名 称 空间 中 创建 资源 对 象 ，ResourceQuota 准 入 控制 器 将 跟 
踪 使 用 情况 以 确保 它 不 超过 相应 ResourceQuota 对 象 中 定义 的 系统 资源 限 
制 。 用 户 创建 或 更 新 资源 的 操作 违反 配额 约束 将 导致 请 求 失败 ，API 
Server 以 HTTP 状 态 代 码 “403FORBIDDEN” 作 为 响应 ， 并 显示 一 条 消息 
以 提示 可 能 违反 的 约束 。 不 过 ， 在 名 称 空间 上 启用 了 CPU 和 内 存 等 系统 
资源 的 配额 后 ， 用 户 创建 Pod 对 象 时 必须 指定 资源 需求 或 资源 限制 ， 否 
则 ， 会 触发 ResourceQuota 准 入 控制 占 拒 绝 执 行 相应 的 操作 。 


ResourceQuota 对 象 可 限制 指定 名 称 空 间 中 非 终 止 状态 的 所 有 Pod 对 
象 的 计算 资源 需求 及 计算 资源 限制 总 量 。 


cpu 或 requests.cpu: CPU 资源 需求 的 总 量 限额 。 


























memory 或 requests.cpu: 内 存 资源 需求 的 总 量 限额 。 

limits.cpu: CPU 资源 限制 的 总 量 限额 。 

limits.memory: 内 存 资源 限制 的 总 量 限 额 。 

ResourceQuota 对 象 文 持 限制 特定 名 称 空间 中 可 以 使 用 的 PVC 数 量 和 
这 些 PVC 资 源 的 空间 大 小 总 量 ， 以 及 特定 名 称 空间 中 可 在 指定 的 
StorageClass 上 使 用 的 PVC 数 量 和 这 些 PVC 资 源 的 总 数 : 


:requests.storage: 所 有 PVC 存 储 需求 的 总 量 限 额 。 











.persistentvolumeclaims: 可 以 创建 的 PVC 总 数 。 


.<S torage-class-name>.storageclass.storage.k8s.io/requests.storage: 指 


定 存储 类 上 可 使 用 的 所 有 PVC 存 储 需 求 的 总 量 限额 。 


‘<s torage-class- 
name>.storageclass.storage.k8s.io/persistentvolumeclaims: 指定 存储 类 上 


可 使 用 的 PVC 总 数 。 
:requests.ephemeral-storage: 所 有 Pod 可 用 的 本 地 临时 存储 需求 的 总 


limits.ephemeral-storage: 所 有 Pod 可 用 的 本 地 临时 存储 限制 的 总 


呈 





在 1.9 版 本 之 前 ，ResourceQuota 支 持 在 名 称 空间 级 别 的 有 限 的 几 种 
资源 集 上 设 定 对 象 计 数 配 额 ， 如 Pods、Services 和 ConfigMAPs 等 ， 而 自 
1.9 版 本 起 支持 以 “count/<resource>.<group>” 的 格式 支持 对 所 有 资源 类 型 
对 象 的 计数 配额 ， 如 countdeployments.apps、count/ 


deployments.extensions 和 Count/services 等 。 


下 面 的 配置 清单 示例 定义 了 一 个 ResourceQuota 资 源 对 象 ， 它 配置 了 
计算 资源 、 存 储 资源 及 对 象 计 数 几 个 维度 的 限额 : 











apiVersion: v1 
kind: ResourceQuota 


metadata: 
name: quota-example 
spec: 
hard: 
pods: "5" 


requests.cpu: "1" 
requests.memory: 16i 

limits.cpu: "2" 

limits,.memory: 2Gi 
count/deployments.apps: "1" 
count/deployments.extensions: "1" 
persistentvolumeclaims: "2" 





创建 完成 后 ，describe 命 令 可 以 打印 其 限额 的 生效 情况 ， 例 如 ， 将 
上 面 的 ResourceQuota 对 象 创 建 于 test 名 称 空 间 中 ， 其 打印 结果 如 下 所 
pa 


一 一 一 一 一 一 一 


~]$ kubectl1 describe quota quota-example -n test 


Name: quota-example 
Namespace: test 
Resource Used Hard 
count/deployments.apps 0 1 
count/deployments .extensions 0 1 
limits,.cpu 0 2 
Jimits ,memory 0 2G1i 
persistentvolumeclaims 0 2 
pods 0 5 
requests.cpu 0 1 
requests.memory 0 1G1i 








在 test 名 称 空 间 中 创建 Deployment 等 对 象 即 可 进行 配额 测试 ， 例 
如 ， 下 面 的 命令 创建 了 一 个 有 着 3 个 Pod 副 本 的 Deployment 对 象 myapp- 
deploy: 





~]$ kubectl run myapp-deploy --image=ikubernetes/myapp:v1 --replicas=3 \ 
--hnamespace=test --requests='cpu=200m,memory=256Mi' --limits='cpu=500m,memory=2: 





创建 完成 后 ，test 名 称 空间 上 的 ResourceQuota 对 象 quota-example 的 
各 配置 属性 也 相应 地 变 成 了 如 下 状态 : 





Resource Used Hard 
count/deployments ,apps 1 2 
count/deployments .extensions 1 2 
Jimits,cpu 1200m 2 
Jimits ,memory 768Mi 2G1i 
persistentvolumeclaims 0 2 
pods 3 5 
requests.cpu 500m 1 
requests.memory 640Mi 16i 





此 时 ， 再 扩展 myapp-deploy 的 规模 则 会 很 快 遇 到 某 一 项 配额 的 限制 
而 导致 扩展 受阻 。 由 分 析 可 知 ， 将 Pod 副 本 数量 扩展 至 5 个 就 会 达到 
limits.cpu 资 源 上 限 而 导致 第 5 个 扩展 失败 。 读 者 可 上 自行 扩展 并 测试 其 结 


O 


需要 注意 的 是 ， 资 源 配额 仪 对 那些 在 ResourceQuota 对 象 创 建 之 后 生 
成 的 对 象 有 效 ， 对 已 经 存在 的 对 象 不 会 产生 任何 限制 。 而 且 ， 一旦 启用 
了 计算 资源 需求 和 计算 资源 限制 配额 ， 那 么 创建 的 任何 Pod 对 象 都 必须 











设置 此 两 类 属性 ， 否 则 Pod 对 象 的 创建 将 会 被 相应 的 ResourceQuota 对 象 
所 阻止 。 无 须 手 动 为 每 个 Pod 对 象 设置 此 两 类 属性 时 ， 可 以 使 用 
LimitRange 对 象 为 其 设置 默认 值 。 


每 个 ResourceQuota 对 象 上 还 文 持 定义 一 组 适用 范围 (scope〉， 用 
于 定义 其 配额 仅 生 效 于 这 组 适用 范围 交集 内 的 对 象 ， 目 前 可 用 的 适用 苑 
围 包括 Terminating、NotTerminating、BestEffort 和 NotBestEffort， 具 体 
说 明 如 下 。 


.Terminating: 匹配 .spec.activeDeadlineSeconds 的 属性 值 大 于 等 于 0 
的 所 有 Pod 对 象 。 


.NotTerminating: 匹配 .spec.activeDeadlineSeconds 的 属性 值 为 空 的 
所 有 Pod 对 象 。 


:BestEffort: 匹配 所 有 位 于 BestEffort QoS 类 别 的 Pod 对 象 。 





:NotBestEffort: 匹配 所 有 非 BestEffort QoS 类 别 的 Pod 对 象 。 


另外 ， 目 1.8 版 本 起 ， 管 理 员 即 可 以 设置 不 同 的 优先 级 类 别 
(PriorityClass) 来 创建 Pod 对 象 ， 而 自 1.11 版 本 起 ，Kubernetes 开 始 支 持 
对 每 个 PriorityClass 对 象 分 别 设 定 资源 限额 ， 管 理 员 可 以 使 用 
scoOpeSelector 字 段 ， 从 而 根据 Pod 对 象 的 优先 级 控制 Pod 资 源 对 系统 资源 
的 消耗 。 


10.6.3 PodSecurityPolicy 


PodSecurityPolicy〔 简 称 PSP〉 是 集群 级 别 的 资源 类 型 ， 用 于 控制 用 
户 在 配置 Pod 资 源 的 期 望 状态 时 可 以 设 定 的 特权 类 的 属性 ， 如 是 否 可 以 
使 用 特权 容器 、 根 命名 空间 和 主机 文件 系统 ， 以 及 可 使 用 的 主机 网 络 和 
端口 、 卷 类 型 和 Linux Capabilities 等 。 不 过 ，PSP 对 象 定义 的 策略 本 身 并 
人 本 ， 它 们 需要 经 由 PodSecurityPolicy 准 入 控制 器 检查 并 
强制 生效 。 


不 过 ，PSP 准 入 控制 器 默认 是 处 于 未 局 用 状态 的 ， 原 因 是 在 未 创建 
任何 PSP 对 象 的 情况 下 启用 此 准 入 控制 器 将 阻止 在 集群 中 创建 任何 Pod 
对 象 。 不 过 ，PSP 资 源 的 API 接 口 (policy/vlbetal/podsecuritypolicy) 独 
并 于 PSP 准 入 控制 嚣 ， 因 此 管理 员 可 以 事先 定义 好 所 需要 的 Pod 安 全 策 
略 ， 而 后 再 设置 kube-apiserver 启 用 PSP 准 入 控制 器 。 不 当 的 Pod 安 全 策略 
可 能 会 产生 难以 预料 的 副作用 ， 因 此 请 确保 所 添加 的 任何 PSP 对 象 都 经 
过 了 充分 的 测试 。 


启用 PSP 准 入 控制 器 后 若 要 部 署 任何 Pod 对 象 ， 则 相关 的 User 
Account 及 Service Account 必 须 全 部 获得 了 恰当 的 Pod 安 全 策略 授权 。 以 
和 常规 用 户 的 刁 份 直接 创建 Pod 对 象 时 ，PSP 准 入 控制 器 将 根据 账户 有 权 
使 用 的 Pod 安 全 策略 验证 其 凭据 。 奉 不 存在 任何 策略 支持 Pod 对 象 安全 性 
要 求 ， 则 会 拒绝 相关 的 创建 操作 。 而 基于 控制 器 (如 Deployment) 创建 
Pod 对 象 时 ，Kubernetes 会 根据 服务 账户 有 权 使 用 的 Pod 安 全 策略 验证 
Pod 的 Service Account 和 凭据 。 知 没有 策略 文 持 Pod 对 象 的 安全 性 要 求 ， 则 
Pod 控 制 右 上 自身 能 够 成 功 创建 ， 但 Pod 对 象 不 会 。 


事实 上 ， 即 便 是 在 启用 了 PSP 准 入 控制 右 的 情况 下 创建 的 PSP 对 象 
也 依然 不 会 发 生效 用 ， 而 是 要 由 授权 插件 〈 如 RBAC) 将 “use” 操 作 权 限 
授权 给 特定 的 Role 或 ClusterRole， 而 后 将 Use Account 或 Service Account 
完成 角色 绑 定 才 可 以 。 下 面 简单 说 明 一 下 设 定 重要 的 Pod 安 全 策略 ， 而 
后 启用 PSP 准 入 控制 器 使 其 生效 的 方法 。 


1. 设 置 特权 及 受 限 的 PSP 对 象 


一 般 说 来 ，system: masters 组 内 的 管理 员 用 户 、system: node 组 内 
的 kubelet， 以 及 kube-system 名 称 空间 中 的 Service Account 需 要 拥有 创建 

















各 类 Pod 对 象 的 授权 ， 包 括 特权 Pod 对 象 。 因 此 ， 首 先 要 创建 一 个 特权 
PSP， 授 予 相关 的 管理 员 权 限 。 一 个 示例 性 的 配置 清单 如 下 : 





apiVersion: policy/v1betal 
kind: PodSecurityPolicy 
metadata: 
name: privileged 
annotations: 
seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*' 
spec: 
privileged: true 
allowPrivilegeEscalation: true 
allowedCapabilities: 


| 


volumes: 


ee 


hostNetwork: true 


hostPorts : 
- min: 0 
max: 65535 


hostIPC: true 
hostPID: true 


runAsUser: 

rule: 'RuNAsAny' 
seLinux: 

rule: 'RuNAsAny' 
supplementalGroups: 

rule: 'RuNAsAny' 
fsGroup: 


rule: 'RuNAsAny' 





相应 地 ， 经 过 API Server 成 功 认 证 的 User Account 或 Service Account 
多 数 都 应 该 具有 创建 非特 权 Pod 对 象 的 授权 ， 因 此 ， 它 们 应 该 获取 受 限 
的 安全 人 策略。 下 面 的 配置 清单 定义 了 一 个 非特 权 的 安全 策略 ， 它 禁止 了 
大 多 数 的 特权 操作 : 








apiVersion: policy/vibeta1 
kind: PodSecurityPolicy 
metadata: 
name: restricted 
annotations: 
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default' 
apparmor .security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' 
seccomp.security.alpha.kubernetes.io/defaultProfileName: 'docker/default' 
apparmor .security.beta.kubernetes.io/defaultProfileName: 'runtime/default' 
spec: 
privileged: false 
# Required to prevent escalations to root. 
allowPrivilegeEscalation: false 
# This is redundant with non-root + disallow privilege escalation, 
# but we can provide it for defense in depth. 
requiredDropCapabilities: 
- ALL 


# Allow core volume types. 
volumes: 
- 'CconfigMap' 
- "emptyDir' 
- "projected ' 
- "Secret 
- "downwardAPI' 
# ASssume that persistentVolumes set Up by the cluster admin are Safe to use. 
- 'persistentVolumeClaim'" 
hostNetwork: false 
hostIPC: false 
hostPID: false 
runAsUser: 
# Require the container to run without root privileges. 
rule: 'MustRunASsNonRoot 
seLinux: 
# This policy assumes the nodes are using AppArmor rather than SELinux. 
rule: "RunASAny 
supplementalGroups: 
rule: 'MustRunNAs' 
ranges: 
# Forbid adding the root group. 
- min: 1 
max: 65535 
fsGroup: 
rule: 'MustRunNAs' 
ranges: 
# Forbid adding the root group. 
- min: 1 
max: 65535 
readonlyRootFilesystem: false 





将 上 述 两 个 配置 清单 中 定义 的 PSP 资 源 提交 并 创建 于 API Server 之 
上 ， 随 后 便 可 授权 特定 的 Role 或 ClusterRole 资 源 通 过 use 进 行 调用 了 。 


2. 创 建 ClusterRole 并 完成 账户 绑 定 
创建 一 个 ClusterRole 对 象 psp: privileged， 授 权 其 可 以 使 用 名 为 


privileged 的 PSP 对 象 ， 并 创建 一 个 ClusterRole 对 象 psp: restricted， 授 权 
其 可 以 使 用 名 为 restricted 的 PSP 对 象 ， 如 下 面 的 配置 清单 所 示 : 








kind: ClusterRole 
apiVersion: rbac.authorization.k8s.io/vi 
metadata: 
name: psp:restricted 
rules: 
- apiGroups: ['policy'] 
resources: ['podsecuritypolicies'] 
verbs: ['use'] 
resourceNames: 
- restricted 


kind: ClusterRole 


apiVersion: rbac.authorization.k8s.io/v1 
metadata: 
name: psp:privileged 
rules: 
- apiGroups: ['policy'] 
resources: ['podsecuritypolicies'] 
verbs: ['use'] 
resourceNames: 
- privileged 





而 后 创建 ClusterRoleBinding 对 象 ， 将 system: masters、system: 
node 和 和 system: serviceaccounts: kube-system 组 的 账户 绑 定 至 psp: 
privileged， 让 它们 拥有 管理 员 权限 ， 并 将 system: authenticated 组 内 的 账 
户 绑 定 至 psp: restricted， 授 予 它们 创建 普通 Pod 对 象 的 权限 : 





apiVersion: rbac.authorization.k8s.io/vi 
kind: ClusterRoleBinding 
metadata: 
name: privileged-psp-user 
roleRef: 
apiGroup: rbac.authorization.k8s.io 
kind: ClusterRole 
name: psp:privileged 


subjects: 
- apiGroup: rbac.authorization.k8s.io 
kind: Group 


name: system:masters 

apiGroup: rbac.authorization.k8s.io 
kind: Group 

name: system:node 

apiGroup: rbac.authorization.k8s.io 
kind: Group 

name: system:serviceaccounts:kube-system 


kind: ClusterRoleBinding 
apiVersion: rbac.authorization.k8s.io/vi 
metadata: 
name: restricted-psp-user 
roleRef: 
kind: ClusterRole 
name: psp:restricted 
apiGroup: rbac.authorization.k8s.io 
subjects: 
- kind: Group 
apiGroup: rbac.authorization.k8s.io 
name: system:authenticated 





3. 启 用 PSP 准 入 控制 器 


待 上 述 步 又 完成 之 后 ， 设 置 kube-apiserver 的 --enable-admission- 
plugins 选 项 ， 在 其 列表 中 添加 “PodSecurityPolicy” 项 目 ， 并 重启 kube- 


apiserver 便 能 启用 PSP 准 入 控制 器 。 而 对 于 使 用 kubeadm 部 蜀 的 
Kubernetes 集 群 来 说 ， 编 辑 Master 节 点 上 的 /etc/kubernetes/manifests/kube- 
apiserver.yaml 配 置 清单 ， 在 其 --enable-admission-plugins 选 项 后 的 列表 上 
添加 “PodSecurity- Policy” 项 目 ， 等 kube-apiserver 相 关 的 Pod 对 象 自动 重 检 
完成 之 后 即 会 启用 PSP 准 入 控制 器 。 


随后 ， 创 建 拥有 特权 securityContext 的 Pod 资 源 配置 清单 ， 并 以 经 过 
认证 的 User Account 或 Service Account 分 别 创建 特权 和 非特 权 的 Pod 对 象 
便 能 验证 Pod 安 全 策略 的 效果 。 例 如 ， 为 前 面 章节 中 创建 的 kube-user1l 使 
用 Rolebinding 对 象 在 test 名 称 空间 绑 定 至 名 为 admin 的 ClusterRole 对 象 ， 
授予 其 test 名 称 空间 的 管理 员 权 限 ， 而 后 再 由 其 尝试 创建 下 面 清单 中 害 
义 的 特权 Pod 对 象 : 











apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-securitycontext 
spec: 
containers: 
- name: busybox 
image: busybox 
imagePullPolicy: IfNotPresent 
command: ["/bin/sh","-c","sleep 86400"] 
securityContext: 
privileged: true 





将 上 面 的 配置 清单 保存 于 配置 文件 中 ， 如 pod-test,yaml， 而 后 进行 
创建 测试 : 





~]$ kubect1l apply -f pod-test.yam]l -n test 

Error from server (Forbidden): error when creating "pod-test.yam1": pods "pod-with- 
securitycontext" is forbidden: unable to validate against any pod security polic 
[spec.containers[0].securityContext.privileged: Invalid value: true: Privileged 
are not allowed] 





命令 结果 显示 创建 操作 被 PSP 定 义 的 策略 所 拒绝 ， 因 为 kube-user1 用 
户 被 归 类 到 system: authenticated 组 中 ， 因 此 被 关联 到 Jrestricted 安 全 策 
略 上 。 移 除 配 置 清单 中 的 security-Context 及 其 散 套 的 字段 再 次 执行 创建 
操作 即 可 成 功 完 成 ， 感 兴趣 的 读者 可 自行 测试 。 男 外 ， 读 者 可 按 此 方式 
授权 特定 的 用 户 拥 有 特定 类 型 的 Pod 对 象 创建 权限 ， 但 策略 冲突 时 可 能 
2 因此 任何 Pod 安 全 策略 在 生效 之 前 请 务必 做 到 

分 测试 。 





10.7 本 章 小 结 


本 章 主 要 讲解 了 Kubernetes 的 认证 、 授 权 及 准 入 控制 相关 的 话题 ， 
其 中 重点 说 明了 以 下 内 容 。 


Kubernetes 系 统 的 认证 、 授 权 及 准 入 控制 插件 的 工作 流程 。 
“Service Account 资 源 及 其 应 用 方式 。 

.HTTPS 客 户 端 证 书 认证 及 其 在 kubectl 和 tls bootstrap 中 的 应 用 。 
.Role 及 RoleBinding 的 工作 机 制 及 应 用 方式 。 

.ClusterRole 及 ClusterRoleBinding 的 工作 机 制 及 其 应 用 方式 。 


.借助 默认 的 ClusterRole 及 ClusterRoleBinding 实 现 集群 及 名 称 空间 级 
别 权 限 的 快速 授予 。 


.Dashboard 及 其 分 级 权限 授予 。 


.使 用 LimitRange 资 源 限 制 名 称 空间 下 容器 、Pod 及 PVC 对 象 的 系统 
资源 限制 。 


.使 用 ResourceQuota 设 置 名称 空 间 的 总 资源 限制 。 
.使 用 PodSecurityPolicy 设 置 创建 Pod 对 象 的 安全 策略 。 


第 11 章 ”网络 模 型 与 网 络 策略 


和 目 Docker 技 术 诞 生 以 来 ， 采 用 容 吉 技术 用 于 开发 、 测 斌 甚至 是 生产 
环境 的 企业 或 组 织 与 日 俱 增 。 然而， 将 容器 拉 术 应 用 于 生产 环境 时 如 何 
确定 合适 的 网 络 方案 依然 是 吸 待 解决 的 最 大 问题 ， 这 也 曾 是 主机 虚拟 化 
时 代 的 著名 难题 之 一 ， 它 不 仅 涉 及 了 网 络 中 各 组 件 的 互 连 互 通 ， 还 需要 
将 容器 与 不 相关 的 其 他 容器 进行 有 效 隔离 以 确保 其 安全 性 。 本 章 将 主要 
讲述 容器 网 络 模型 的 进化 、Kubernetes 的 网 络 模型 、 常 用 网 络 插件 以 及 
网 络 策略 等 相关 的 话题 。 


11.1 Kubernetes 网 络 模 型 及 CNI 插 件 


Docker 的 传统 网 络 模型 在 应 用 至 日 趋 复 杂 的 实际 业务 场景 时 必 将 导 
致 复杂 性 的 几何 级 数 上 升 ， 由 此 ，Kubernetes 设 计 了 一 种 网 络 模型 ， 它 
要 求 所 有 容器 都 能 够 通过 一 个 局 平 的 网 络 平面 直接 进行 通信 (在 同一 IP 
网 络 中 ) ， 无 论 它 们 是 否 运 行 于 集群 中 的 同一 节点 。 不 过 ,在 
Kubernetes 集 群 中 ，IP 地 址 分 配 是 以 Pod 对 象 为 单位 ， 而 非 容 器 ， 同 一 
Pod 内 的 所 有 容器 共享 同一 网 络 名 称 空间 。 





11.1.1 Docker 容 器 的 网 络 模型 


Docker 容 堪 网 络 的 原始 模型 主要 有 三 种 : Bridge 桥接) 、 
Host〈 主 机 ) 及 Container 〈 容 器 ) 。Bridge 模 型 借助 于 虚拟 网 桥 设 备 为 
容器 建立 网 络 连接 ，Host 模 型 则 设 定 容器 直接 共享 使 用 节点 主机 的 网 络 
名 称 空 间 ， 而 Container 模 型 则 是 指 多 个 容器 共享 同一 个 网 络 名称 空 间 ， 
从 而 彼此 之 间 能 够 以 本 地 通信 的 方式 建立 连接 。 


Docker 守 护 进 程 首次 启动 时 ， 它 会 在 当前 节点 上 创建 一 个 名 为 
docker0 的 桥 设 备 ， 并 默认 配置 其 使 用 172.17.0.0/16 网 络 ， 该 网 络 是 
Bridge 模 型 的 一 种 实现 ， 也 是 创建 Docker 容 器 时 默认 使 用 的 网 络 模型 。 
如 图 11-1 所 示 ， 创 建 Docker 容 器 时 ， 默 认 有 四 种 网 络 可 供 选择 使 用 ， 从 
而 表现 出 了 四 种 不 同类 型 的 容器 ， 具 体 如 下 。 


.Closed container (封闭 式 容器 ，: 此 类 容器 使 用 “None” 网 络 ， 它 们 
没有 对 外 通信 的 网 络 接口 ， 而 是 仪 具有 LO 接口 ， 通 常 仪 用 于 不 需要 网 
络 的 后 端 作业 处 理 场 景 。 


Bridged container( 桥 接 式 容 器 〉: 此 类 容器 使 用 “Bridge” 模 型 的 网 
络 ， 对 于 每 个 网 络 接口 ， 容 器 引擎 都 会 为 每 个 容器 创建 一 对 两 个 ) 虚 
拟 以 太 网 设备 ， 一 个 配置 为 容器 的 接口 设备 ， 另 一 个 则 在 节点 主机 上 接 
入 指定 的 虚拟 网 桥 设 备 〈 默 认为 docker0) 。 


:Open container 〈 开 放 式 容器 ) : 此 类 容器 使 用 “Host”* 模 型 的 网 
络 ， 它 们 共享 使 用 Docker 主 机 的 网 络 及 其 接口 。 


.Joined container (联盟 式 容 器 ) : 此 类 容器 共享 使 用 某 个 已 存在 的 
容 絮 的 网 络 名 称 空间 ， 即 共享 并 使 用 指定 的 容器 的 网 络 及 其 接口 。 
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图 11-1 Docker 容 器 网 络 


上 述 的 容器 间 通 信 仅 描述 了 同一 市 皮 上 的 容 费 间 通 信和 的 可 用 方 双 ， 
这 应 该 也 是 Docker 设 计 者 早期 最 为 关注 的 容器 通信 目标。 然而 ， 在 生产 
环境 中 使 用 容器 撤 术 时 ， 跨 节点 的 容 需 间 通 信 反 倒 更 为 钟 抑 ， 可 根据 网 
络 类 型 将 其 实现 方式 简单 划分 为 如 下 几 种 。 


-为 各 Docker 节 点 创建 物理 网 络 桥接 接口 ， 设 定 各 节点 上 的 容 髓 使 
用 此 桥 设 备 从 而 直接 其 露 于 物理 网 络 中 。 


配置 各 节点 上 的 容器 直接 共享 使 用 其 节点 的 网 络 名 称 空间 。 
-将 容器 接 入 指定 的 桥 设 备 ， 如 docker0， 并 设置 其 借助 NAT 机 制 进 


行 通 信 。 

第 三 种 方案 是 较为 流行 且 默 认 的 解决 方案 。 不 过 ， 此 种 方案 的 
IPAM (IP Address Management) 是 基于 容器 主机 本 地 范围 进行 的 ， 
个 节点 上 的 容器 都 将 从 同一 个 网 络 172.17.0.0/16 中 获取 IP 地 址 ， 这 就 意 
味 着 不 同 Docker 主 机 上 的 容器 可 能 会 使 用 相同 的 地 址 ， 因 此 它们 也 就 无 
法 直接 通信 。 














解决 此 问题 的 通行 方式 是 为 NAT。 所 有 接 入 到 此 桥 设备 上 的 容器 均 
会 被 NAT 隐 藏 ， 它 们 发 往 Docker 主 机 外 部 的 所 有 流量 都 会 在 执行 过 源 地 
址 转换 后 发 出 ， 并 且 默 认 是 无 法 直接 接收 节点 之 外 的 其 他 主机 发 来 的 请 
求 的 。 硝 要 接 入 Docker 主 机 外 部 的 流量 ， 则 需要 事先 通过 目标 地 址 转换 
甚至 额外 的 端口 转换 将 其 暴露 于 外 部 网 络 中 ， 如 图 11-2 所 示 。 
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故此 ， 传 统 的 解决 方 采 中 ， 多 市 点 上 的 Docker 容 右 间 通信 依赖 于 
NAT 机 制 转 发 实现 。 这 种 解决 方案 在 网 络 规模 庞大 时 将 变 得 极为 复杂 、 
对 系统 资源 的 消耗 较 大 且 转 发 效率 低下 。 此 外 ，docker host 的 端口 也 是 
一 种 稀缺 资源 ， 静 态 分 配 和 映射 极 易 导致 冲突 ， 而 动态 分 配色 很 容易 导 
致 模型 的 进一步 复杂 化 。 


事实 上 ，Docker 网 络 也 可 借助 于 第 三 方 解 决 方案 来 规避 NAT 通 信 模 
型 导致 的 复杂 化 问题 ， 后 来 还 发 布 了 CNM (Container Network Model) 
规范 ， 现 在 已 经 被 Cisco Contiv、Kuryr、Open Virtual 
Networking (OVN) 、Project Calico、VMware 或 Weave 这 些 公 司 和 项 目 
所 采纳 。 不 过 ， 这 种 模型 被 采用 时 ， 也 就 属于 了 容 吉 编排 的 范畴 。 











11.1.2 ”Kubernetes 网 络 模 型 


Kubernetes 的 网 络 模型 主要 可 用 于 解雇 四 类 通信 需求 : 同一 Pod 内 容 
器 间 的 通信 (Container to Container) 、Pod 间 的 通信 (Pod to Pod) 、 
Service 到 Pod 间 的 通信 (Service to Pod) 以 及 集群 和 部 与 Service 之 间 的 


通信 (external to Service) 。 
(1) 容器 间 通 信 


Pod 对 象 内 的 各 容器 共享 同一 网 络 名 称 空间 ， 它 通常 由 构建 Pod 对 象 
的 基础 架构 容器 所 提供 ， 例 如 ， 由 pause 镜 像 启 动 的 容器 。 所 有 运行 于 
同一 个 Pod 内 的 容器 与 同一 主机 上 的 多 个 进程 类 似 ， 彼此 之 间 可 通过 la 
接口 完成 交互 ， 如 图 11-3 所 示 ，Pod P 内 的 Container1 和 Container2 之 间 的 
通信 即 为 容器 间 通 信 。 


(2) Pod 间 通信 


各 Pod 对 象 需要 运行 于 同一 个 平面 网 络 中 ， 每 个 Pod 对 象 拥 有 一 个 集 
群 全 局 唯一 的 地 址 并 可 直接 用 于 与 其 他 Pod 进 行 通信 ， 如 图 11-3 中 的 Pod 
P 和 Pod Q 之 间 的 通信 。 此 网 络 也 称 为 Pod 网 络 。 男 外 ， 运 行 Pod 的 各 节点 

也 会 通过 桥接 设备 等 持 有 此 平面 网 络 中 的 一 个 IP 地 址 ， 如 图 11-3 中 的 
cbr0 接 口 ， 这 就 意味 着 Node 到 Pod 间 的 通信 也 可 在 此 网 络 上 直接 进行 。 
和 J 通信 或 Pod 到 Node 间 的 通信 比较 类 似 于 同一 IP 网 络 中 主机 

进行 的 通信 
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图 11-3” Pod 网 络 


此 类 通信 模型 中 的 通信 需求 也 是 Kubernetes 的 各 网 络 插件 需要 着 力 
解决 的 问题 ， 它 们 的 实现 方式 有 舍 加 网 络 模 型 和 路 由 网 络 模型 等 ， 流 行 
的 解决 方案 有 十 数 种 之 多 ， 例 如 前 面 使 用 到 的 flannel。 


(3) Service 与 Pod 间 的 通信 


Service 资 源 的 专用 网 络 也 称 为 集群 网 络 〈Cluster Network) ， 需 要 
在 启动 kube-apiserver 时 经 由 “--service-cluster-ip-range” 选 项 进行 指定 ， 如 
10.96.0.0/12， 而 每 个 Service 对 象 在 此 网 络 中 均 拥 一 个 称 为 Cluster-IP 的 
定 地 址 。 管 理 员 或 用 户 对 Service 对 象 的 创建 或 更 改 操 作 由 API Server 存 
储 完 成 后 触发 各 节点 上 的 kube-proxy， 并 根据 代理 模式 的 不 同 将 其 定义 
为 相应 节点 上 的 iptables 规 则 或 ipvs 规 则 ， 借 此 完成 从 Service 的 Cluster-IP 
与 Pod-IP 之 间 的 报 文 转 友 ， 如 图 11-4 所 示 。 
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图 11-4 Service 和 和 Pod 
(4) 集群 外 部 到 Pod 对 象 之 间 的 通信 


将 集群 外 部 的 流量 引入 到 Pod 对 象 的 方式 有 受 限 于 Pod 所 在 的 工作 节 
点 范围 的 节点 端口 (nodePort) 和 主机 网 络 (hostNetwork) 两 种 ， 以 及 
工作 于 集群 级 别 的 NodePort 或 LoadBalancer 类 型 的 Service 对 象 。 不 过 ， 
即便 是 四 层 代 理 的 模式 也 要 经 由 两 级 转发 才能 到 达 目 标 Pod 资 源 : 请 求 
流量 首先 到 达 外 部 负载 均衡 器 ， 由 其 调度 至 某 个 工作 节点 之 上 ， 而 后 再 
由 工作 节点 的 netfilter (kube-proxy〉 组 件 上 的 规则 (iptables 或 ipvs) 调 
度 至 某 个 目标 Pod 对 象 。 


以 上 4 种 通信 方法 的 具体 应 用 方式 在 前 面 的 章节 中 己 有 详细 描述 ， 
因此 这 里 不 再 给 出 更 进一步 的 说 明 。 














11.1.3 Pod 网 络 的 实现 方式 


每 个 Pod 对 象 内 的 基础 架构 容器 均 使 用 一 个 独立 的 网 络 名 称 空间 ， 
并 共 至 给 同一 Pod 内 的 其 他 容 右 使 用 。 每 个 名 称 空间 均 有 其 专用 的 独立 
网 络 协议 栈 及 其 相关 的 网 络 接口 设备 。 一 个 网 络 接口 仅 能 属于 一 个 网 络 
名 称 空 间 ， 于 是 ， 运 行 多 个 Pod 必 然 要 求 使 用 多 个 网 络 名 称 空间 ， 也 就 
需要 用 到 多 个 网 络 接口 设备 。 不 过 ， 一 个 易于 实现 的 方案 是 使 用 软件 实 
现 的 伪 网 络 接口 及 模拟 线 统 将 其 连接 至 物理 接口 。 伪 网 络 接口 的 实现 方 
采 第 见 的 有 虚拟 网 桥 、 多 路 复 用 及 人 硬件 交换 三 种 ， 如 图 11-5 所 示 。 


:虚拟 网 桥 : 创建 一 对 虚拟 以 太 网 接口 (veth) ， 一 个 接 入 容器 内 
部 ， 另 一 个 留置 于 根 名 称 空间 内 并 借助 于 Linux 内 核 桥 接 功能 或 
OpenVSwitch (OVS) 关联 至 真实 的 物理 接口 。 


.多 路 复 用 : 多 路 复 用 可 以 由 一 个 中 间 网 络 设备 组 成 ， 它 暴露 了 多 
个 虚拟 接口 ， 可 使 用 数据 包 转 发 规则 来 控制 每 个 数据 包 转 到 的 目标 接 
口 。MACVLAN 为 每 个 虚拟 接口 配置 一 个 MAC 地 址 并 基于 此 地 址 完成 
二 层 报 文 收 发 ， 而 IPVLAN 是 基于 IP 地 址 的 并 使 用 单个 MAC， 从 而 使 其 
更 适合 VM。 


-人 硬件 交换 ， 现今 市 面 上 的 大 多 数 NIC 都 支持 单 根 I/O 虚 拟 化 (SR- 
IOV) ， 它 是 创建 虚拟 设备 的 一 种 实现 方式 。 每 个 虚拟 设备 自身 均 表 现 
为 一 个 独立 的 PCI 设 备 ， 并 有 着 自己 的 VLAN 及 与 硬件 强制 关联 的 QoS。 
SR-IOV 提 供 了 接近 硬件 级 别 的 性 能 ， 但 在 公共 云 中 通常 是 不 可 用 的 。 


大 多 数 情 况 下 ， 用 户 希 望 创建 跨越 多 个 L2 或 L3 的 逻辑 网 络 子 网 ， 
这 就 要 借助 于 闭 加 封装 协议 来 实现 (最 常见 的 是 VXLAN， 它 将 羞 加 流 
量 封装 到 UDP 数据 包 中 ) 。 不 过 ， 由 于 控制 平面 缺乏 标准 化 ，VXLAN 
可 能 会 引入 更 高 的 开销 ， 并 且 来 自 不 同 供应 商 的 多 个 VXLAN 网 络 通 第 
无 法 互 操作 。 而 Kubernetes 还 将 大 量 使 用 iptables 和 NAT 来 拦截 进入 逻辑 / 
虚拟 地 址 的 流量 并 将 其 路 由 到 适当 的 物理 目的 地 。 
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图 11-5 ”虚拟 网 桥 、 多 路 复 用 及 硬件 交换 


无 论 上 述 哪 种 方式 应 用 于 容器 环境 中 ， 其 实现 过 程 都 需要 大 量 的 操 
作 步 又。 不 过 ， 目 前 Kubernetes 文 持 使 用 CNI 插 件 来 编排 网 络 ， 以 实现 
Pod 及 集群 网 络 管理 功能 的 自动 化 。 每 次 Pod 被 初始 化 或 删除 时 ，kubelet 
都 会 调用 默认 的 CNI 搬 件 创建 一 个 虚拟 设备 接口 附加 到 相关 的 抵 层 网 
络 ， 为 其 设置 IP 地 址 、 路 由 信息 并 将 其 映射 到 Pod 对 象 的 网 络 名 称 空 
间 。 


配置 Pod 的 网 络 时 ，kubelet 首 先 在 默认 的 /etc/cni/net.d/ 目 录 中 查找 
CNI JSON 配 置 文 件 ， 接 着 基于 type 属 性 到 /opt/cni/bin/ 中 查找 相关 的 插件 
二 进 制 文件 ， 如 下 面 示例 中 的 “portmap”。 随 后 ， 由 CNI 插 件 调用 IPAM 
插件 〈IP 地 址 管理 ) 来 设置 每 个 接口 的 IP 地 址 ， 如 host-local 或 dhcp 等 : 








~]$ cat /etc/cni/net.d/10-flannel.conflist 
{ 


"name": "cbrO", 
"plugins": [ 
{ 


"type": "flannel", 
"delegate": { 
"hairpinMode": true, 
"isDefaultGateway": true 
} 
}, 
{ 
"type": "portmap", 
"capabilities": { 
"portMappings": true 


kubelet 基 于 包含 命令 参数 CNI_ ARGS、CNIL COMMAND、 
CNIL IFNAME、CNIL NETNS、CNIL CONTAINERID、CNL PATH 的 环 
境 变量 调用 CNI 插 件 ， 并 经 由 stdin 流 式 传 输 json.conf 文 件 。 被 调用 的 插 
件 使 用 JSON 格 式 的 文本 信息 进行 啊 应 ， 描 述 操作 结果 和 状态 。 借 助 于 
插件 框架 ， 有 着 熟练 的 Go 编程 语言 能 力 的 读者 ， 可 以 轻松 开发 出 自己 
的 CNI 插 件 ， 或 者 扩展 现 有 插件 。 


配置 网 络 接口 时 ，kubelet 将 Pod 对 象 的 名 称 和 名 称 空间 作为 
CNL_ ARGS 变 量 的 一 部 分 进行 传递 
(如 “K8S_POD_ NAMESPACE=default; K8 S_POD_NAME=myapp- 
6d9f48c5d9-n77qp; ”) 。 它 可 以 定义 每 个 Pod 对 象 或 Pod 网 络 名 称 空间 的 
网 络 配置 〈 例 如， 将 每 个 网 络 名 称 空间 放 在 不 同 的 子 网 中 ) 。 未 来 的 
Kubernetes 版 本 将 网 络 视 为 一 等 的 公民 ， 并 将 网 络 配置 作为 Pod 对 象 或 名 
称 空间 规范 的 一 部 分 ， 就 像 内 存 、CPU 和 存储 卷 一 样 。 目 前 ， 可 以 使 用 
注解 〈annotations) 来 存储 配置 或 记录 Pod 网 络 数据 /状态 。 

















11.1.4 ”CNI 插 件 及 其 常见 的 实现 


Kubernetes 设 计 了 网 络 模型 ， 但 将 其 实现 交 给 了 网 络 插件 。 于 是 ， 
各 种 解决 方案 不 断 涌现 。 为 了 规范 及 兼容 各 种 解决 方案 ，CoreOS 和 
Google 联 合 制定 了 CNI 〈Container Network Interface) 标准 ， 旨 在 定义 容 
器 网 络 模型 规范 。 它 连接 了 两 个 组 件 : 容器 管理 系统 和 网 络 插件 。 它 们 
之 间 通 过 JSON 格 式 的 文件 进行 通信 ， 以 实现 容器 的 网 络 功能 。 有 基体 的 
工作 均 由 插件 来 实现 ， 包 括 创建 容器 netns、 关 联网 络 接口 到 对 应 的 
netns 以 及 为 网 络 接口 分 配 卫 等 。CNI 的 基本 思想 是 : 容器 运行 时 环境 在 
创建 容器 时 ， 先 创建 好 网 络 名 称 空间 Cnetns) ， 然 后 调用 CNI 插 件 为 这 
个 netns 配 置 网 络 ， 而 后 再 局 动容 器 内 的 进程 。 


CNI 本 号 只 是 规范 ， 付 诸 生产 还 需要 有 特定 的 实现 。 目 前 ，CNI 提 
供 的 插件 分 为 三 类 : main、meta 和 ipam。main 一 类 的 插件 主要 在 于 实现 
某 种 特定 的 网 络 功能 ， 例 如 loopback、bridge、macvlan 和 和 ipvlan 等 ; meta 
一 类 的 插件 自 号 并 不 提供 任何 网 络 实 现 ， 而 是 用 于 调用 其 他 插件 ， 例 如 
调用 flannel;，ipam 仅 用 于 分 配 卫 地 址 ， 而 不 提供 网 络 实现 。 


CNI 具 有 很 强 的 扩展 性 和 灵活 性 ， 例 如 ， 如 果 用 户 对 某 个 插件 具有 
额外 的 需求 ， 则 可 以 通过 输入 中 的 args 和 环境 变量 CNI_ARGS 进 行 传 
递 ， 然 后 在 插件 中 实现 自 定义 的 功能 ， 这 大 大 增加 了 它 的 扩展 性 。 男 
外 ，CNI 插 件 将 main 和 ipam 分 开 ， 赋 予 了 用 户 自由 组 合 它们 的 机 制 ， 其 
至 一 个 CNI 插 件 也 可 以 直接 调用 另外 一 个 CNI 插 件 。CNI 目 前 已 经 是 
Kubernetes 当 前 推荐 的 网 络 方案 。 常 见 的 CNI 网 络 插 件 包含 如 下 这 些 主 
流 的 项 目 。 


:Flannel: 一 个 为 Kubernetes 提 供 徐 加 网 络 的 网 络 插件 ， 它 基于 
Linux TUN/TAP， 使 用 UDP 封 装 IP 报 文 来 创建 奢 加 网 络 ， 并 借助 etcd 维 
护 网 络 的 分 配 情况 。 


Calico: 一 个 基于 BGP 的 三 层 网 络 插件 ， 并 且 也 支持 网 络 策略 来 实 
现 网 络 的 访问 控制 ; 它 在 每 台 机 器 上 运行 一 个 vRouter， 利 用 Linux 内 核 
来 转发 网 络 数据 包 ， 并 借助 iptables 实 现 防火 墙 等 功能 。 


.Canal: 由 Flannel 和 Calico 联 合 发 布 的 一 个 统一 网 络 插件 ， 提 供 CNI 
网 络 插 件 ， 并 支持 网 络 策略 。 


























"Weave Net: Weave Net 是 一 个 多 主机 容器 的 网 络 方案 ， 文 持 去 中 
心 化 的 控制 平面 ， 在 各 个 host 上 的 wRouter 间 建立 Full Mesh 的 TCP 连 接 ， 
并 通过 Gossip 来 同步 控制 信息 。 


数据 平面 上 ，Weave 通 过 UDP 封装 实现 L2Overlay， 封 装 文 持 两 种 
模式 ， 一 种 是 运行 在 user space 的 sleeve mode， 另 一 种 是 运行 在 kernal 
space 的 fastpath mode。 


-Contiv: 思科 开源 的 容器 网 络 方案 ， 主 要 提供 基于 Policy 的 网 络 管 
理 ， 并 与 主流 容器 编排 系统 集成 ，Contiv 最 主要 的 优势 是 直接 提供 了 多 
租户 网 络 ， 并 支持 L2 (VLAN) 、L3 (BGP) 、Overlay (VXLAN) 
A 





.OpenContrail: Juniper 推 出 的 开源 网 络 虚 拟 化 平台 ， 其 商业 版 本 为 
Contrail。 其 主要 由 控制 器 和 vRouter 组 成 ， 控 制 器 提供 虚拟 网 络 的 配 
置 、 控 制 和 分 析 功 能 ，vRouter 则 提供 分 布 式 路 由 ， 负 责 虚 拟 路 由 器 、 
虚拟 网 络 的 建立 及 数据 转发 。 


:Romana: 由 Panic Networks 于 2016 年 释 出 的 开源 项 目 ， 和 在 借鉴 路 
由 汇聚 (route aggregation) 的 思路 来 解决 辣 加 方案 为 网 络 带 来 的 开销 。 


:NSX-T: 由 VMware 提供 ， 用 于 定义 敏捷 SDI (Software-Defined 
Infrastructure) 以 构建 云 原 生 应 用 环境 ; 其 旨 在 合并 异 构 端 点 或 技术 栈 
的 应 用 框架 和 架构 ， 如 vSphere、KVM、 容 器 和 bare metal 等 。 





.kube-router: kube-router 是 Kubernetes 网 络 的 一 体 化 解决 方案 ， 它 
可 取代 kube-proxy 实 现 基于 ipvs 的 Service， 能 为 Pod 提 供 网 络 ， 支 持 网 络 
策略 以 及 拥有 完美 兼容 BGP 的 高 级 特性 。 


上 述 的 CNI 网 络 插件 在 实现 方式 、 传 输 性 能 、 功 能 特性 等 方面 存在 
着 不 小 的 差别 ， 部 团 时 ， 用 户 需 要 根据 网 络 环 境 和 业务 需要 等 来 选择 合 
适 的 项 目 。 不 过 ， 束 目前 的 统计 (https://thenewstack.io ) 来 看 ，flannel 
和 calico 两 个 项 目 是 最 为 流行 的 选择 ， 如 图 11-6 所 示 。 
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图 11-6 ”CNI 网 络 插件 的 采用 率 统计 情况 〈( 含 多 选 ) 


随 着 Kubernetes 的 演进 ， 必 将 涌现 出 越 来 越 多 的 CNI 插 件 ， 它 们 各 
具 特 色 ， 各 有 优 务 。 实 践 中 ， 用 户 根 据 实际 需要 选择 合用 的 方案 即 可 。 
本 章 将 介绍 flannel 和 calico 两 种 主流 的 方案 及 其 部 署 和 应 用 ， 不 过 ， 男 一 
个 非常 值得 关注 的 解决 方案 是 kube-router。 





11.2 fannel 网 络 插件 


各 Docker 主 机 在 docker0 桥 上 默认 使 用 同一 个 子 网 ， 不 同 节点 的 容 右 
很 可 能 会 得 到 相同 的 地 址 ， 于 是 跨 节 点 的 容器 间 通 信 会 面临 地 址 冲突 的 
问题 。 另 外 ， 即 使 人 为 地 设 定 多 个 节点 上 的 docker0 桥 使 用 不 同 的 子 
网 ， 其 报 文 也 会 因为 在 网 络 中 缺乏 路 由 信息 而 无 法 准确 送 达 。 事 实 上 ， 
各 种 CNI 插 件 都 至 少 要 解决 这 两 类 问题 。 


对 于 第 一 个 问题 ，flannel 的 解雇 办 法 是 ， 预 留 使 用 一 个 网 络 ， 如 
10.244.0.0/16， 而 后 自动 为 每 个 节点 的 Docker 容 器 引擎 分 配 一 个 子 网 ， 
如 10.244.1.0/24 和 10.244.20/24， 并 将 其 分 配 信息 保存 于 etcd 持 久 存 储 。 
对 于 第 二 个 问题 ，flannelj 有 着 多 种 不 同 的 处 理 方法 ， 每 一 种 处 理 方法 也 
可 以 称 为 一 种 网 络 模型 ， 或 者 称 为 flannel 使 用 的 后 端 。 


:VxLAN: Linux 内 核 自 3.7.0 版 本 起 支持 VxLAN，flannel 的 此 种 后 端 
ee 内 核 中 的 VxLAN 模 块 封装 报 文 ， 这 也 是 flannel 较 为 推荐 使 用 
方式。 














图 11-7 VxLAN 协 议 报 文 


:host-gw: 即 Host GateWay， 它 通过 在 节点 上 创建 到 达 目 标 容 器 地 
址 的 路 由 直接 完成 报 文 转发 ， 因 此 这 种 方式 要 求 各 市 点 本 映 必须 在 同一 
个 二 层 网 络 中 ， 故 该 方式 不 太 适 用 于 较 大 的 网 络 规模 (大 二 层 网 络 除 
外 ) 。host-gw 有 着 较 好 的 转发 性 能 ， 且 易于 设 定 ， 推 荐 对 报 文 转发 性 
能 要 求 较 高 的 场景 使 用 。 


UDP: 使 用 普通 UDP 报 文 封闭 完成 隧道 转 及 ， 其 性 能 较 前 两 种 方 
式 要 低 很 多 ， 仅 应 该 在 不 文 持 前 两 种 方式 的 环境 中 使 用 。 


flannel 初 创 之 后 的 一 段 时 期 内 ， 不 少 环境 中 的 Linux 发 行 版 的 内 核 尚 
且 不 文 持 VxLAN， 而 host-gw 模 式 有 着 略 高 的 网 络 技术 门槛 ， 故 此 大 多 




















数 部 署 场景 只 好 使 用 UDP 模式 ，flannel 因 而 不 幸 地 落下 性 能 不 好 的 声 
名 。 不 过 ， 目 前 flannel 的 部 署 默 认 后 端 已 经 是 琶 加 网 络 模型 VxLAN 。 男 
外 ， 除 了 这 三 种 后 端 之 外 ，flannel 还 实验 性 地 支持 AliVPC、AWS 
VPC、Alloc 和 GCE 几 种 后 端 。 





11.2.1 _ flannel 的 配置 参数 


为 了 跟踪 各 子 网 分 配 信息 等 ，flannel 使 用 etcd 来 存储 虚拟 IP 和 主机 
IP 之 间 的 映射 ， 各 个 节点 上 运行 的 flanneld 守 护 进 程 负 责 监视 etcd 中 的 信 
忧 并 完成 报 文 路 由 。 默 认 情 况 下 ，flannel 的 配置 信息 保存 于 etcd 的 键 
名 /coreos.com/network/config 之 下 ， 可 以 使 用 etcd 服 务 的 客户 端 工 具 来 设 
定 或 修改 其 可 用 的 相关 配置 。config 的 值 是 一 个 JSON 格 式 的 字典 数据 结 
构 ， 它 可 以 使 用 的 键 包含 以 下 几 个 。 


1) Network: flannel 于 全 局 使 用 的 CIDR 格 式 的 IPv4 网 络 ， 字 符 串 格 
起 ， 此 为 必 选 键 ， 余下 的 均 为 可 选 。 


2) SubnetLen: 将 Network 属 性 指定 的 IPv4 网 络 基于 指定 位 的 掩 码 
切割 为 供 各 节点 使 用 的 子 网 ， 此 网 络 的 掩 码 小 于 24 时 (如 16)〉 ， 其 切割 
子 网 时 使 用 的 掩 码 默 认为 24 位 。 


3) SubnetMin: 可 用 作 分 配给 节点 使 用 的 起 始 子 网 ， 默 认为 切 分 完 
成 后 的 第 一 个 子 网 ; 字符 串 格 式 。 


4) SubnetMax: 可 用 作 分 配给 节点 使 用 的 最 大 子 网 ， 默 认为 切 分 完 
成 后 最 大 的 一 个 子 网 ， 字 符 串 格式 。 


5) Backend: flannel 要 使 用 的 后 端 类 型 ， 以 及 后 端的 相关 配置 ， 字 
典 格式 ; VxLAN、host-gw 和 UDP 后 端 各 有 其 相关 的 参数 。 


例如 下 面 的 配置 示例 中 ， 全 局 网 络 为 "10.244.0.0/16”， 切 分 子 网 时 
用 到 的 捧 码 长 度 为 24， 将 相应 的 子 网 10.244.0.0/24-10.244.255.0/24 分 别 
分 配给 每 一 个 工作 节点 使 用 ， 选 择 VxLAN 作 为 使 用 的 后 端 类 型 ， 并 监 
上 听 于 8472 端 口 : 











{ 
"Network": "10.244.0.0/16", 
"SubnetLen": 24 
"Backend": { 
"Type": "VxLAN", 
"Port": 8472 
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以 上 配置 信息 可 直接 由 flannel 保 存 于 etcd 存 储 中 ， 也 可 交 由 
Kubernetes 进 行 存 储 。 有 具体 使 用 的 方式 取 雇 于 管理 员 或 部 署 程序 的 默认 
配置 。 男 外 ，flannel 默 认 使 用 VxLAN 后 端 ， 但 VxLAN direct routing 和 
host-gw 却 有 着 更 好 的 性 能 表现 。 





11.2.2 ”VXxLAN 后 并 和 direct routing 


VxLAN， 人 全称 Virtual extensible Local Area Network (虚拟 可 扩展 局 
域 网 ) ， 是 VLAN 扩 展 方案 草案 ， 采 用 的 是 MAC in UDP 封装 方式 ， 是 
NVo3 (CNetwork Virtualization over Layer3) 中 的 一 种 网 络 虚 拟 化 技术 ， 
如 图 11-8 所 示 。 有 具体 实现 方式 为 : 将 虚拟 网 络 的 数据 帧 添加 到 VxLAN 首 
部 后 ， 封 装 在 物理 网 络 的 UDP 报 文中 ， 然 后 以 传统 网 络 的 通信 方式 传送 
该 UDP 报 文 ， 待 其 到 达 目 的 主机 后 ， 去 挥 物理 网 络 报 文 的 头 部 信息 以 及 
VxLAN 首 部 ， 然 后 将 报 文 交付 给 目的 终端 ， 如 图 11-9 所 示 的 拓扑 结构 
中 ， 跨 节点 的 Pod 间 通信 即 为 如 此 。 不 过 ， 整 个 过 程 中 通信 双方 对 物理 
网 络 无 所 感知 。 
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图 11-8 ”flannel VxLAN 后 端 
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图 11-9 ”flannel VxLAN Direct Routing 后 端 





VxLAN 技 术 的 引入 使 得 逻辑 网 络 拓扑 和 物理 网 络 拓扑 实现 了 一 定 
程度 的 解 厢 ， 网 络 拓 扑 的 配置 对 于 物理 设备 的 配置 的 依赖 程度 有 所 降 
低 ， 配 置 更 灵活 更 方便 。 另 外 ，VLAN 技 术 解 决 了 二 层 网 络 广播 域 分 割 
的 问题 ， 提 供 了 多 租户 的 民 好 支持 ， 通 过 VxLAN 进 行 分 割 ， 各 个 租户 
可 以 独立 组 网 、 通 信 。 但 是 ， 为 了 确保 VxLAN 机 制 通信 过 程 的 正确 
性 ， 涉 及 VxLAN 通 信 的 IP 报 文 一 律 不 能 分 片 ， 这 就 要 求 在 物理 网 络 的 链 
路 层 实现 中 必须 提供 足够 大 的 MTU 值 ， 或 者 修改 其 MTU 值 以 保证 
VxLAN 报 文 的 顺利 传输 。 不 过 ， 降 低 默认 MTU 值 ， 以 及 额外 的 首部 开 
销 ， 必 然 会 影响 到 其 报 文 传输 性 能 。 


对 于 Kubernetes 1.7 及 以 后 的 版 本 来 襄 ，flannel 项 目 官方 给 出 的 在 线 
配置 方式 清单 中 的 默认 配置 即 为 VxLAN 后 端 ， 它 定义 在 kube-system 名 
称 空间 ConfigMap 资 源 kube-flannel-cfg 中 ， 它 以 10.244.0.0/16 为 Pod 网 络 
地 址 ， 其 配置 内 容 如 下 上 所 示 : 











net-conf.json: | 


"Network": "10.244.0.0/16", 
"Backend": { 
"Type": "VxLAN" 





另外 ， 它 将 通过 名 为 kube-flannel-ds 的 DaemonSet 控 制 器 资源 ， 在 每 


个 节点 运行 一 个 flannel 相 关 的 Pod 对 象 。DaemonSet 控 制 器 的 Pod 模 板 中 
使 用 “hostNetwork: true” 配 置 每 个 节点 上 的 Pod 资 源 直接 共享 使 用 节点 的 
网 络 名 称 空 间 以 完成 网 络 配 置 ， 其 配置 结果 直接 生效 于 节点 的 根 网 络 名 


称 空间 。 


传统 的 VxXLAN 后 端 使 用 隧道 网 络 转发 登 加 网 络 的 通信 报 文 会 导致 
不 少 的 流量 开销 ， 于 是 flannel 的 VxLAN 后 端 还 支持 DirectRouting 模 式 ， 
它 通 过 添加 必要 的 路 由 信息 使 用 节点 的 二 层 网 络 直接 发 送 Pod 的 通信 报 
文 ， 仪 在 跨 IP 网 络 时 ， 才 启用 传统 的 隧道 方式 转发 通信 流量 。 由 于 大 部 
分 场景 中 都 省 去 了 隧道 首部 开销 ， 因 此 DirectRouting 通 信和 模式 的 性 能 其 
本 接近 于 直接 使 用 二 层 物 理 网 络 ， 其 架构 模型 如 图 11-9 所 示 。 


将 flannel 项 目 官 方 提供 的 配置 清单 下 载 至 本 地 ， 如 存储 为 Master 节 
点 上 的 /etc/kubernetes/manifests/kube-flannel.yaml 文 件 ， 而 后 将 其 
ConfigMap 资 源 kube-flannel-cfg 的 data 字 段 中 的 网 络 配置 部 分 修改 为 如 下 
内 容 所 示 ， 并 使 用 “kubectl apply” 命 令 重 新 应 用 于 集群 中 即 可 : 











net-conf.json: | 


"Network": "10.244.0.0/16", 
"Backend": { 
"Type": "VxLAN", 
"Directrouting": true 


} 





配置 完成 后 ， 在 每 个 节点 上 执行 路 由 查看 命令 “ip route show” 可 以 
看 到 其 生成 的 路 由 规则 ， 如 下 所 示 的 结果 是 在 本 书 的 部 署 示 例 拓 扑 环境 
中 的 node01 上 生成 的 路 由 信息 ， 其 中 ，10.244.1.0/24 网 络 位 于 本 机 上 
(node01 市 点 ) ， 其 他 的 目标 网 络 则 分 别 位 于 集群 中 的 每 个 主机 之 上 ， 
包括 master 闻 点 : 








10.244.0.0/24 via 172.16.0.70 dev ens33 
10.244.1.0/24 dev cniQ proto kernel scope link src 10.244.1.1 
10.244.2.0/24 via 172.16.0.67 dev ens33 
10.244.3.0/24 via 172.16.0.68 dev ens33 





此 时 ， 在 各 个 集群 节点 上 执行 “iptables-nL”* 命 令 可 以 看 到 ，iptables 
filter 表 的 FORWARD 链 上 由 其 生成 了 如 下 两 条 转发 规则 ， 它 显 式 放 行 了 
10.244.0.0/16 网 络 进出 的 所 有 报 文 ， 用 于 确保 由 物理 接口 接收 或 发 送 的 


目标 地 址 或 源 地 址 为 10.244.0.0/16 网 络 的 所 有 报 文 均 能 够 正常 通行 。 这 
些 是 Direct Routing 模式 得 以 实现 的 必要 条 件 : 





target prot opt source destination 
ACCEPT all -- 10.244.0.0/16 0.0.0.0/0 
ACCEPT all -- 0.0.0.0/0 10.244.0.0/16 


各 个 市 点 上 依然 存在 flannel 相 关 接 口 ， 原 因 是 对 于 那些 无 法 通过 直 
接 路 由 到 达 的 主机 上 的 Pod〈 非 同一 个 二 层 网 络 ) ， 它 依然 是 采用 
VxLAN 的 隧道 转发 机 制 。 按 需 启 动 两 个 Pod 测 试 其 通信 ， 并 通过 相关 接 
口 捕获 通信 报 文 即 可 分 析 其 结果 。 


© 注意 “为 了 保证 所 有 Pod 均 能 得 到 正确 的 网 络 配置 ， 建 议 在 
创建 Pod 资 源 之 前 事先 配置 好 网 络 插件 ， 甚 至 是 事先 了 解 并 根据 自身 业 
务 需 求 测试 完成 中 意 的 目标 网 络 插件 ， 在 选 型 完成 后 再 部 署 Kubernetes 
集群 ， 而 尽量 避免 中 途 修改 ， 人 否则 有 些 Pod 资 源 可 能 会 需要 重建 。 














VxLAN Directrouting 后 端 转 发 模式 同时 兼 具 了 VxLAN 后 端 和 host- 
人 既 保证 了 传输 性 能 ， 又 具备 了 路 二 层 网 络 转发 报 文 的 
能 力 。 

另外 ，VxLAN 后 端的 可 用 配置 参数 除了 Type 之 外 还 有 如 下 几 个 ， 
它们 都 有 其 默认 值 ， 在 用 户 需要 自 定 义 参 数 时 可 显 式 给 出 相关 的 配置 。 








:Type: VxLAN， 字 符 串 。 
-VNI: VxLAN 的 标识 符 ， 默 认为 1， 数 值 型 数据 。 


-Port: 用 于 发 送 封装 的 报 文 的 UDP 端口 ， 默 认为 8472; 数值 型 数 
据 。 


-GBP: 全 称 为 Group Based Policy， 配 置 是 否 启用 VxLAN 的 基于 组 
的 策略 机 制 ， 默 认为 否 ; 布尔 型 数据 。 


:DirectRouting: 是 否 为 同一 个 二 层 网 络 中 的 节点 启用 直接 路 由 机 
制 ， 类 似 于 host-gw 后 端的 功能 ;， 此 种 场景 下 ，VxLAN 仪 用 于 为 那些 不 
在 同一 个 二 层 网 络 中 的 节点 封装 并 转发 报 文 ; 布尔 型 数据 。 








11.2.3 host-gw 后 端 


host-gw 后 端 通过 添加 必要 的 路 由 信息 使 用 节点 的 二 层 网 络 直接 发 
送 Pod 的 通信 报 文 ， 其 工作 方式 类 似 于 VxLAN 后 端 中 direct routing 的 功 
能 ， 但 不 包括 其 VxLAN 的 隧道 转发 能 力 。 其 工作 模型 示意 图 如 图 11-10 
所 示 。 


编辑 kube-flannel 配 置 清 单 ， 将 ConfigMap 资 源 kube-flannel-cfg 的 data 
字段 中 网 络 配 置 部 分 修改 为 如 下 所 示 的 内 容 ， 并 使 用 “kubectl apply” 命 
令 重 新 应 用 于 集群 中 即 可 配置 fannel 使 用 host-gw 后 端 : 





net-conf.json: | 


"Network": "10.244.0.0/16", 
"Backend": { 
"Type": "host-gw" 
} 
} 
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图 11-10 ”host-gw 后 端 


配置 完成 后 ， 各 节点 会 生成 类 似 于 VxLAN direct routing 一 样 的 路 由 
及 iptables 规 则 以 实现 二 层 转发 Pod 网 络 的 通信 报 文 ， 省 去 了 隧道 转发 模 
和 不 过 ， 对 于 非 同 一 个 二 层 网 络 的 报 文 的 转发 ，host-gw 
则 无 能 为 力 。 











类 似 host-gw 或 VxLAN direct routing 这 种 使 用 静态 路 由 的 方式 来 实现 
二 层 转发 虽然 较 之 VxLAN 有 着 更 低 的 资源 开销 和 更 好 的 性 能 表现 ， 但 
在 Kubernetes 集 群 规模 较 大 时 其 路 由 信息 的 规模 也 将 变 得 庞大 且 不 易 维 


» 


护 。 


此 外 ，flannel 自 身 并 不 具备 为 Pod 网 络 实施 网 络 策略 以 实现 其 网 络 
通信 隔离 的 能 力 ， 但 它 能 够 借助 于 Canal 项 目 构建 网 络 策略 功能 。 


11.3 网络 策略 


网 络 策略 (Network Policy) 是 用 于 控制 分 组 的 Pod 资 源 彼此 之 间 如 
何 进行 通信 ， 以 及 分 组 的 Pod 资 源 如 何 与 其 他 网 络 端点 进行 通信 的 规 
范 。 它 用 于 为 Kubernetes 实 现 更 为 精细 的 流量 控制 ， 实 现 租户 隅 离 机 
制 。Kubernetes 使 用 标准 的 资源 对 象 *NetworkPolicy” 供 管理 员 按 需 定 义 
网 络 访问 控制 策略 。 


11.3.1 ”网络 策略 概述 


Kubernetes 的 网 络 策略 功能 由 其 所 使 用 的 网 络 插件 实现 ， 因 此 ， 仅 
在 使 用 那些 支持 网 络 策略 功能 的 网 络 插件 时 才能 够 配置 网 络 策 略 ， 如 
Calico、Canal 及 kube-router 等 。 每 种 解决 方案 各 有 其 特定 的 网 络 策略 实 
现 方式 ， 它 们 的 实现 或 依赖 于 节点 上 自身 的 功能 ， 或 借助 于 Hypervisor 的 
特性 ， 也 可 能 是 网 络 自身 的 功能 。Calico 的 calico/kube-controllers 即 为 
Calico 项 目 中 用 于 将 用 户 定义 的 网 络 策略 予以 实现 的 组 件 ， 它 主要 依赖 
于 节点 的 iptables 来 实现 访问 控制 功能 ， 如 图 11-11 所 示 。 其 他 支持 网 络 
策略 的 插件 也 有 类 似 的 将 网 络 策略 加 以 实现 的 “策略 控制 器 * 或 “策略 引 
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图 11-11 网 络 策略 组 件 构架 
策略 控制 器 用 于 监控 创建 Pod 时 所 生成 的 新 API 端 点 ， 并 按 需 为 其 附 
加 网 络 策略 。 当 发 生 需 要 配置 策略 的 事件 时 ， 侦 听 器 会 监视 到 变化 ， 控 
制 器 随即 响应 以 进行 接口 配置 和 策略 应 用 。 


Pod 的 网 络 流量 包含 “流入 ”(Ingress) 和 “流出 ”(Egress) 两 种 方 








癌 ， 每 种 方向 的 控制 倘 略 则 包含 “允许 "和 “至 止 ”* 两 种 。 默 认 情 况 下 ， 
Pod 处 于 非 隔离 状态 ， 它 们 的 流量 可 以 自由 来 去 。 一 旦 有 末 略 通过 选择 
强 规 则 将 策略 应 用 于 Pod， 那 么 所 有 未 经 明确 允许 的 流量 都 将 被 网 络 贷 
略 拒绝 ， 不 过 ， 其 他 未 被 选 择 器 匹配 到 的 Pod 不 受 影 响 。 


© 注意 ”Kubernetes 自 1.8 版 本 起 才 支 持 Egress 网 络 策略 ， 此 前 的 
版 本 仪 支持 Ingress 网 络 策略 。 


11.3.2 ”部 署 Canal 提 供 网 络 策略 功能 


Canal 代 表 了 针对 云 原 生 应 用 程序 的 最 佳 策略 网 络 解 决 方案 ， 旨 在 
让 用 户 轻 松 地 将 Calico 和 flannel 网 络 部 署 在 一 起 作为 统一 的 网 络 解 决 方 
案 ， 将 Calico 的 网 络 策略 执行 与 Calico 和 flannel 疼 加 以 及 非 炙 加 网 络 连 接 
选项 的 丰富 功能 相 结 合 ， 如 图 11-12 所 示 。 
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图 11-12 ”Canal 项 目 架 构 组 件 


换 句 话说 ，Calico 项 目 既 能 够 独立 地 为 Kubernetes 集 群 提供 网 络 解决 
方案 和 网 络 策 略 ， 也 能 与 flannel 结 合 在 一 起 ， 由 flannel 提 供 网 络 解决 方 
案 ， 而 Calico 此 时 仅 用 于 提供 网 络 策略 ， 这 时 我 们 也 可 以 将 Calico 称 为 
Canal。Calico 将 数据 存储 于 etcd 中 ， 它 支持 选择 使 用 专用 的 etcd 存 储 ， 
os 以 Kubernetes API Server 作 为 后 端 存储 ， 这 里 选择 以 第 二 种 方式 
进行 。 


© 注意 “结合 flannel 工 作 时 ，Calico 提 供 的 默认 配置 清单 中 是 以 
flannel 默 认 使 用 的 10.244.0.0/16 为 Pod 网 络 ， 因 此 ， 请 确保 kube- 
controller-manager 程 序 在 启动 时 通过 --cluster-cidr 选 项 设置 使 用 了 此 网 络 
地 址 ， 并 且 --allocate-node-cidrs 的 值 应 设置 为 true。 





部 署 之 前 ， 要 在 启用 了 RBAC 的 Kubernetes 集 群 中 设置 必要 的 相关 
资源 : 





~]$ kubectl1 apply -f https://docs.projectcalico.org/v3.2/getting-started/kubernetes, 
installation/hosted/canal/rbac.yaml 





接 下 来 即 可 部 署 Canal 提 供 网 络 策略 : 





~]$ kubect1 apply -f https://docs.projectcalico.org/v3.2/getting-started/kubernetes, 
installation/hosted/canal/canal.yaml 





需要 注意 的 是 ，Canal 目 前 直接 使 用 Calico 和 flannel 项 目 ， 代 码 本 映 
并 没有 任何 修改 。 因 此 ， 目 前 的 Canal 只 是 一 种 部 署 模 式 ， 用 于 安装 和 
配置 项 目 ， 从 用 户 和 编排 系统 的 角度 无 颖 地 作为 单一 网 络 解决 方案 协同 
工作 。 未 来 ，Canal 项 目 可 能 会 对 Calico 和 flannel 项 目 进 行 代 码 更 改 ， 实 
现 安装 和 配置 的 进一步 人 简化。 











11.3.3 ”配置 网 络 策略 


Kubernetes 系 统 中 ， 报 文 流 入 和 流出 的 核心 组 件 是 Pod 资 源 ， 因 此 它 
们 也 是 网 络 策略 功能 生效 的 主要 目标 ， 因 此 ，NetworkPolicy 对 象 也 要 使 
用 标签 选择 器 事先 选择 出 一 组 Pod 资 源 作为 控制 对 象 。 一 般 来 说 ， 
NetworkPolicy 是 定义 在 一 组 Pod 资 源 上 的 用 于 管控 入 站 流量 的 “Ingress 规 
则 »， 或 者 说 是 管理 出 站 流量 的 “Egress 规则 ， 也 可 以 是 二 者 组 合 定义 ， 
0 以 定义 ， 如 图 
11-13 所 不 。 

















者 Network 
odSelector ; 
P Policy 
/ SN 2 
AN Egress ，” ， 
J 一 OPDorts 
| / pA 、 l » 
\ \ | 
N Pod | / 
SY / » Es 
N ports trom 
\ 7 Ineress 





图 11-13 ”网络 策略 示意 图 


默认 情况 下 ，Pod 对 象 既 可 以 接受 来 自任 何 来 源 的 流量 ， 也 能 够 问 
外 部 发 出 期 望 的 所 有 流量 。 而 附加 网 络 策 略 机 制 后 ，Pod 对 象 会 因 
NetworkPolicy 对 象 的 选 定 而 被 隔离 ， 一旦 名 称 空间 中 有 任何 
NetworkPolicy 对 象 罗 配 了 某 特 定 的 Pod 对 象 ， 则 该 Pod 将 拒绝 Network- 
Policy 所 不 允许 的 一 切 连接 请 求 ， 而 那些 未 被 任何 NetworkPolicy 对 象 匹 
配 到 的 其 他 Pod 对 象 仍 可 接受 所 有 流量 。 因 此 ， 就 特定 的 Pod 集 合 来 说 ， 
入 站 和 出 站 流量 默认 均 处 于 放行 状态 ， 除 非 有 规则 能 够 明确 匹配 到 它 。 
然而 ， 一 旦 在 spec.policyTypes 中 指定 了 生效 的 规则 类 型 ， 却 在 
networkpolicy.spec 字 上 段 中 骸 套 定义 了 没有 任何 规则 的 Ingress 或 Egress 字 
段 时 ， 则 表示 拒绝 相关 方向 上 的 一 切 流 量 。 











定义 网 络 策略 时 常用 到 的 术语 及 说 明 具 体 如 下 。 


.Pod 组 : 由 网 络 策 略 通 过 Pod 选 择 器 选 定 的 一 组 Pod 的 集合 ， 它 们 是 
规则 生效 的 目标 Pod; 可 由 NetworkPolicy 对 象 通过 macthLabel 或 
matchExpression 选 定 。 


'Egress: 出 站 流量 ， 即 由 特定 的 Pod 组 发 往 其 他 网 络 疹 点 的 流量 ， 
通常 由 流量 的 目标 网 络 端点 (to) 和 端口 〈ports) 来 进行 定义 。 


Ingress: 入 站 流量 ， 即 由 其 他 网 络 端点 及 往 特定 Pod 组 的 流量 ， 通 
常 由 流量 发 出 的 源 站 点 (from) 和 流量 的 目标 端口 所 定义 。 


:端口 (ports) : TCP 或 UDP 的 端口 号 。 


.端点 〈to，from) : 流量 目标 和 流量 源 相 关 的 组 件 ， 它 可 以 是 
CIDR 格 式 的 IP 地 址 块 〈ipBlock) 、 网 络 名 称 空间 选择 器 
(namespaceSelector)[ 罗 配 的 名 称 空间 ， 或 Pod 选 择 嚣 (podSelector) 匹 
配 的 Pod 组 。 


无 论 是 mgress 还 是 Egress 流 量 ， 与 选 定 的 某 Pod 组 通信 的 另 一 方 都 可 
使 用 “网 络 端 点 ”予以 描述 ， 它 通常 是 某 名 称 空间 中 的 一 个 或 一 组 Pod 资 
源 ， 由 namespaceSelector 选 定名 称 空间 后 ， 经 由 ijpBlock 或 podSelector 进 
行 指定 。Pod 集 合 的 选 定 方式 如 图 11-14 所 示 。 
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图 11-14 ”Pod 和 集合 的 选 定 方 式 


在 mgress 规 则 中 ， 网 络 端点 也 称 为 “ 源 端点 ”， 它 们 用 from 字 段 进行 
标识 ， 而 在 Egress 规 则 中 ， 网 络 端点 也 称 为 “目标 端点 ” 它们 用 to 字段 
进行 标识 ， 如 图 11-13 所 示 。 不 过 ， 在 未 定义 Ingress 或 Egress 规 则 时 ， 相 
关 方 向 的 流量 均 为 “允许 "”， 即 默认 为 非 隔离 状态 。 而 一 旦 在 
networkpolicy.spec 中 明确 给 出 了 Ingress 或 Egress 字 段 ， 则 它们 的 from 或 to 
字段 的 值 束 成 了 白 名 单列 表 ， 而 空 值 意味 着 所 有 端点 ， 即 不 限制 访问 。 

















11.3.4 ”管控 入 站 流量 





以 提供 服务 为 主要 目的 的 Pod 对 象 通常 是 请 求 流量 的 目标 对 象 ， 但 
它们 的 服务 未 必 应 该 为 所 有 网 络 端点 所 访问 ， 这 就 有 必要 对 它们 的 访问 
许可 施加 控制 。networkpolicy.spec 中 散 套 的 Ingress 字 段 用 于 定义 入 站 流 
量规 则 ， 就 特定 的 Pod 集 合 来 说 ， 入 站 流量 默认 处 于 放行 状态 ， 除 非 在 
所 有 入 站 策略 中 ， 至 少 有 一 条 规则 能 够 明确 匹配 到 它 。Imgress 字 段 的 值 
是 一 个 对 象 列表 ， 它 主要 由 以 下 两 个 字段 组 成 。 


from<[]Object>: 可 访问 当前 策略 匹配 到 的 Pod 对 象 的 源 地 址 对 象 
列表 ， 多 个 项 目 之 间 的 逻辑 关系 为 “逻辑 或 ”的 关系 ; 大 未 设置 此 字段 或 
其 值 为 空 ， 则 匹配 一 切 源 地 址 《默认 的 访问 策略 为 不 限制 ) ;如 果 此 字 
段 至 少 有 一 个 值 ， 那 么 它 将 成 为 放行 的 源 地 址 白 名 单 ， 仅 来 源 于 此 地 址 
列表 中 的 流量 允许 通过 。 


.ports<[]Object>: 当前 策略 匹配 到 的 Pod 集 合 的 可 被 访问 的 端口 对 
象 列表 ， 多 个 项 目 之 间 的 逻辑 关系 为 “ 迎 辑 或 ”的 关系 ; 各 未 设置 此 字段 
或 其 值 为 空 ， 则 匹配 Pod 集 合 上 的 所 有 端口 〈 默 认 的 访问 策略 为 不 限 
制 ) ;如 果 此 字段 至 少 有 一 个 值 ， 那 么 它 将 成 为 允许 被 访问 的 Pod 端 口 
日 名 单列 表 ， 仪 入 站 流量 的 目标 端口 处 于 此 列表 中 方才 准许 通过 。 


需要 注意 的 是 ，NetworkPolicy 资 源 属 于 名 称 空间 级 别 ， 它 的 有 效 作 
用 范围 为 其 所 属 的 名 称 空间 。 


1. 设 置 默认 的 Ingress 策 略 


必要 时 ， 用 户 可 以 创建 一 个 NetworkPolicy 来 为 名 称 空间 设置 一 
个 “默认 ”的 隔离 策略 ， 该 策略 选择 所 有 的 Pod 对 象 ， 而 后 允许 或 拒绝 任 
何 到 达 这 些 Pod 的 入 站 流量 。 例 如 下 面 的 策略 示例 ， 其 通过 policyTypes 
字段 指明 要 生效 Ingress 类 型 的 规则 ， 但 未 定义 任何 Ingress 字 段 ， 因 此 不 
能 匹配 到 任 一 源 端点 ， 从 而 拒绝 所 有 入 站 流量 : 























apiVersion: networking.k8s.io/vi 
kind: NetworkPolicy 
metadata: 
name: deny-all-ingress 
spec: 
podSelector: {} 


policyTypes: ["Ingress"] 








奉 要 将 默认 集 略 设置 为 允许 所 有 的 入 站 流量 ， 则 只 需要 显 式 定义 
Ingress 字 段 ， 并 将 其 值 设 置 为 空 以 下 配 所 有 源 端 点 即 可 ， 如 下 面 示例 中 
的 定义 。 不 过 ， 没 有 为 入 站 流量 定义 任何 规则 时 ， 本 号 的 默认 规则 即 为 
允许 访问 ， 因 此 允许 所 有 相关 的 入 站 流量 时 ， 本 身 无 须 定义 默认 规则 ， 
下 面 的 示例 只 是 为 说 明 规则 的 定义 格式 : 























apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy 
metadata: 
name: allow-all-ingress 
spec: 
podSselector: {} 
policyTypes: ["Ingress"] 
Ingress : 


= 





实践 中 ， 通 常 将 默认 全 略 设置 为 拒绝 所 有 的 入 站 流量 ， 而 后 显 式 放 
行 允许 的 源 端 点 的 入 站 流量 。 


2. 放 行 特定 的 入 站 流量 


在 mgress 规 则 中 藤 套 from 和 ports 字 段 即 可 匹配 特定 的 入 站 流量 ， 仅 
定义 from 字 段 时 将 隐 含 本 地 Pod 资 源 组 的 所 有 端口 ， 而 仅 定 义 ports 字 段 
时 则 表示 隐 舍 所 有 的 源 端点 。from 和 ports 同 时 定义 时 表示 隐 仿 “人 逻辑 
与 ?关系 ， 它 将 匹配 那些 同时 满足 fom 和 ports 的 定义 的 入 站 流量 ， 即 那 
些 来 自 from 指 定 的 源 端点 ， 访 问 由 当前 NetworkPolicy 的 podSelector 匹 配 
的 当前 名 称 空间 的 Pod 资 源 组 上 上 所 指定 的 ports 的 请 求 ， 如 图 11-15 所 示 。 
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图 11-15 ”Ingress 规 则 的 组 成 方式 


from 字 段 的 值 是 一 个 对 象 列 表 ， 它 可 能 套 使 用 ipBlock、 
namespaceSelector 和 podSelector 字 段 来 定义 流量 来 源 ， 此 三 个 字段 匹配 
0 同 ， 同 时 使 用 两 个 或 以 上 的 字段 ， 彼 此 之 间 隐 
含 “ 远 辑 或 ”关系 。 


-ipBlock<Object> : 根据 IP 地 址 或 网 络 地 址 块 选择 流量 源 端 点 。 


namespaceSelector<Object> : 基于 集群 级 别 的 标签 挑选 名 称 空间 ， 
它 将 匹配 由 此 标签 选择 器 选 出 的 所 有 名 称 空间 内 的 所 有 Pod 对 象 ; 赋予 
0 和 的 名 称 空间 ， 即 源 站 点 为 所 有 名 称 空 间 内 的 
Pod 对 角 。 


.podSelector<Object> : 于 NetworkPolicy 所 在 的 当前 名 称 空间 内 基于 
标签 选择 器 挑选 Pod 资 源 ， 赋 予 字段 以 空 值 来 表示 挑选 当前 名 称 空间 内 
的 所 有 Pod 对 象 。 


:ports 字 段 的 值 也 是 一 个 对 象 列表 ， 它 舱 套 port 和 protocol 来 定义 流 
量 的 目标 端口 ， 即 由 NetworkPolicy 匹 配 到 的 当前 名 称 空 间 内 的 所 有 Pod 
资源 上 的 端口 。 











:port<string>: 端口 号 或 在 Container 上 定义 的 端口 名 称 ， 未 定义 时 
匹配 所 有 端口 。 


'Drotocol<string>: 传输 层 协议 的 名 称 ，TCP 或 UDP， 默 认为 TCP。 


下 面 配置 清单 中 的 网 络 策略 示例 定义 了 如 何 开放 myapp pod 资 源 给 
相应 的 源 站 点 访问 : 





apiVersion: networking.k8s.io/vi 
kind: NetworkPolicy 
metadata: 
name: allow-myapp-ingress 
namespace: default 
spec: 
podSelector: 
matchLabels: 
app: myapp 
policyTypes: ["Ingress"] 
Ingress : 
- from: 
- ipBlock: 
cidr: 10.244.0.0/16 
except: 
- 10.244.3.0/24 
- podSelector: 
matchLabels: 
app: myapp 
ports: 
- protocol: TCP 
port: 80 





它 将 default 名 称 空间 中 拥有 标签 “app=myapp” 的 Pod 资 源 的 80/TCP 端 
口 开 放 给 10.244.0.0/16 网 络 内 除 10.244.3.0/24 子 网 中 的 所 有 源 端 点 ， 以 及 
当前 名 称 空间 中 拥有 标签 “app=myapp” 的 所 有 Pod 资 源 访问 ， 其 他 未 匹配 
到 的 源 端 点 的 流量 则 取决 于 其 他 网 络 策略 的 定义 ， 若 没有 任何 匹配 策 
略 ， 则 默认 为 允许 访问 。 


11.3.5 ”管控 出 站 流量 


除非 是 仅 于 当前 名 称 空间 中 即 能 完成 万 有 的 目标 功能 ， 否 则 ， 大 多 
数 情况 下 ， 一 个 名 称 空间 中 的 Pod 资 源 总 是 有 对 外 请 求 的 需求 ， 如 回 
CoreDNS 请 求解 析 名 称 等 。 因 此 ， 通 常 应 该 将 出 站 流量 的 默认 集 略 设置 
为 准许 通过 。 但 如 果 有 必要 对 其 实施 精细 管理 ， 仪 放行 那些 有 对 外 请 求 
需要 的 Pod 对 象 的 出 站 流量 ， 则 也 可 先 为 名 称 空间 设置 “禁止 所 有 ”默认 
打上 略 ， 而 后 定义 明确 的 准许” 抹 略 。 


networkpolicy.spec 中 舱 套 的 Egress 字 段 用 于 定义 入 站 流量 规则 ， 就 
特定 的 Pod 集 合 来 说 ， 出 站 流量 一 样 默认 处 于 放行 状态 ， 除 非 在 所 有 入 
站 策略 中 至 少 有 一 条 规则 能 够 明确 匹配 到 它 。Egress 字 段 的 值 是 一 个 字 
段 列 表 ， 它 主要 由 以 下 两 个 字段 组 成 。 


to<[]Object> : 由 当前 全 略 迈 配 到 的 Pod 资 源太 起 的 出 站 流量 的 目 
标 地 址 列表 ， 多 个 项 目 之 间 为 “或 ”(OR) 关系 ; 知 未 定义 或 字段 值 为 
空 则 童 味 着 应 用 于 所 有 目标 地 址 (默认 为 不 限制 ); 寿 明 确 给 出 了 主机 
地 址 列表 ， 则 只 有 目标 地 址 匹配 列表 中 的 主机 地 址 的 出 站 流量 被 放行 。 


:ports<[]Object> : 出 站 流量 的 目标 端口 列表 ， 多 个 端口 之 间 
为 “或 ”(OR) 关系 ; 硝 示 定义 或 字段 值 为 空 则 意味 着 应 用 于 所 有 浅 口 
默认 为 不 限制 ) ; 重 明 确 给 出 了 端口 列表 ， 则 只 有 目标 端口 匹配 列表 
中 的 奖 口 的 出 站 流量 被 放行 。 


Egress 规 则 中 ，to 和 ports 字 段 的 值 都 是 对 象 列表 格式 ， 它 们 可 内 蔡 
的 字段 分 别 与 ngress 规 则 中 的 from 和 ports 相 同 ， 区 别 仅 是 作用 到 的 流量 
方向 相反 ， 如 图 11-16 所 示 。 
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图 11-16 ” Egress 字段 的 组 成 方式 
1. 设 置 默认 Egress 策 略 


类 似 于 使 用 Ingress 的 使 用 方式 ， 用 户 也 可 以 通过 创建 一 个 
NetworkPolicy 对 象 来 为 名 称 空间 设置 一 个 默认 的 隔离 策略 ， 该 策略 选择 
所 有 的 Pod 对 象 ， 而 后 允许 或 拒绝 由 这 些 Pod 发 出 的 所 有 出 站 流量 。 例 如 
下 面 的 策略 示例 ， 它 通过 policyTypes 字 段 指明 要 生效 Egress 类 型 的 规 
则 ， 但 未 定义 任何 Egress 字 段 ， 因 此 不 能 匹配 到 任何 目标 端点 ， 从 而 拒 
绝 所 有 的 入 站 流量 : 








apiVersion: networking.k8s.io/vi1 
kind: NetworkPolicy 
metadata: 
name: deny-all-egress 
spec: 
podSselector: {} 
policyTypes: ["Egress"] 





实践 中 ， 需 要 进行 严格 隔离 的 环境 通常 将 默认 策略 设置 为 拒绝 所 有 
出 站 流量 ， 而 后 显 式 放行 允许 到 达 的 目标 端点 的 出 站 流量 。 
2. 放 行 特定 的 出 站 流量 

下 面 的 配置 清单 示例 中 定义 了 一 个 Egress 规 则 ， 它 对 来 自 拥 
有 “app=tomcat” 的 Pod 对 象 的 ， 到 达标 俭 为 <app=nginx” 的 Pod 对 象 的 80 端 


口 ， 以 及 到 达标 签 为 "app=mysqP 的 Pod 对 象 的 3306 端 口 的 流量 给 予 放 
行 : 


一 


apiVersion: networking.k8s.io/vi 
kind: NetworkPolicy 
metadata: 
name: allow-tomcat-egress 
namespace: default 
spec: 
podSelector: 
matchLabels: 
app: tomcat 
policyTypes: ["Egress"] 
egress: 
- to: 
- podSelector: 
matchLabels: 
app: nginx 
ports: 
- protocol: TCP 
port: 80 
- to: 
- podSelector: 
matchLabels: 
app: mysql 
ports: 
- protocol: TCP 
port: 3306 





需要 注意 的 是 ， 此 配置 清单 中 仅 定义 了 出 站 规则 ， 将 入 站 流量 的 默 
认 规 则 设置 为 拒绝 所 有 时 ， 还 应 该 为 具有 标签 “app=tomcat” 的 Pod 对 象 放 
行 入 站 流量 。 





-| 
by 


11.3.6 ”隔离 名 称 空 间 





实践 中 ， 通 常 需要 彼此 隔离 所 有 的 名 称 空间 ， 但 应 该 允许 它们 都 能 
够 与 kube-system 名 称 空间 中 的 Pod 资 源 进 行 流量 交换 ， 以 实现 监控 和 名 
称 解析 等 各 种 管理 功能 。 下 面 的 配置 清单 示例 为 default 名 称 空间 定义 了 
相关 的 规则 ， 在 出 站 和 入 站 流量 默认 均 为 拒绝 的 情况 下 ， 它 用 于 放行 名 
称 空间 内 部 的 各 Pod 对 象 之 间 的 通信 ， 以 及 与 kube-system 名 称 空 间 内 各 
Pod 间 的 通信 : 





apiVersion: networking.k8s.io/vi 
kind: NetworkPolicy 
metadata: 
name: namespace-deny-all 
namespace: default 
spec: 
policyTypes: ["Ingress","Egress"] 
podSselector: {} 


apiVersion: networking.k8s.io/vi 
kind: NetworkPolicy 
metadata: 
name: namespace- 
namespace: default 
spec: 
policyTypes: ["Ingress","Egress"] 
podSselector: {} 
ingress: 
- from: 
- namespaceSelector: 
matchExpressions: 
- key: name 
operator: In 
values: ["default","kube-system"] 
egress: 
- to: 
- namespaceSelector: 
matchExpressions: 
- key: name 
operator: In 
values: ["default","kube-system"] 











需要 注意 的 是 ， 有 些 管理 员 可 能 会 把 一 些 系统 附件 部 署 到 专 有 的 名 
称 空间 中 ， 例 如 把 Prometheus 监 控 系 统 部 晋 到 prom 名 称 空间 中 等 ， 所 有 
这 类 的 具有 管理 功能 的 附件 所 在 的 名 称 空 间 与 每 一 个 特定 名 称 空 间 的 出 
入 流量 都 应 该 被 放行 。 





11.3.7 网络 策略 应 用 案例 


假设 有 名 为 testing 的 名 称 空间 内 运行 着 一 组 nginx Pod 和 一 组 myapp 
Pod。 要 求实 现 如 下 目标 。 


1) myapp Pod 仅 允许 来 自 nginx Pod 的 流量 访问 其 80/TCP 端 口 ， 但 
可 以 向 nginx Pod 的 所 有 端口 发 出 出 站 流量 。 


2) nginx Pod 人 允许 任何 源 端 点 对 其 8O/TCP 端 口 的 访问 ， 并 能 够 向 任 
意 端 点 发 出 出 站 流量 。 


3) myapp Pod 和 nginx Pod 都 可 与 kube-system 名 称 空间 的 任意 Pod 进 
全 任何 类 型 的 通信 ， 以 便于 可 以 使 用 由 kube-dns 提 供 的 名 称 解析 服务 








如 图 11-17 所 示 ， 出 站 和 入 站 的 默认 策略 均 为 “禁止 ”。 


namespace testing 
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图 11-17 案例 拓扑 
下 面 是 测试 实现 步骤 。 


第 一 步 : 创建 testing 名 称 空间 ， 并 于 其 内 基于 Deployment 控 制 器 创 
建 用 于 测试 用 的 nginx Pod 和 myapp Pod 各 一 个 ， 创 建 相关 Pod 资 源 时 顺便 
为 其 创建 与 Deployment 控 制 器 同名 的 Service 资 源 : 





~]$ kubectl create namespace testing 
~]$ kubectl run nginx --image=nginx:alpine --replicas=1 --namespace=testing \ 


--port 80 --expose --labels app=nginx 
~]$ kubectl1 run myapp --image=ikubernetes/myapp:v1 --replicas=1 \ 
--namespace=testing --port 80 --expose --labels app=myapp 





另外 ， 为 了 便于 在 网 络 策略 规则 中 引用 kube-system 名 称 空间 ， 这 里 
为 其 添加 标签 “ns=kube-system”: 





~]$ kubect1 label namespace kube-system ns=kube-system 





竺 相关 资源 创建 完成 后 ， 即 可 通过 与 其 相关 的 Service 资 源 的 名 称 访 
问 相 关 的 服务 。 例 如 ， 男 外 局 动 一 个 终端 ， 使 用 kubectl 命 令 在 default 名 
称 空间 中 创建 一 个 用 于 测试 的 临时 交互 式 客 户 端 : 





~]$ kubect1l run cirros-$RANDOM --namespace=default --rm -it --image=cirros -- sh 
/ # 





而 后 基于 此 客户 端 分 别 测试 访问 nginx 和 myapp 的 服务 ， 名 称 空 间 的 
默认 网 络 集 略为 准许 访问 ， 接 下 来 确认 其 访问 请 求 可 正常 通过 : 





/ # curl nginx.testing 


/ # curl myapp.testing 
Hello MyApp | Version: vi | <a href="hostname.html">Pod Name</a> 
/ # 





第 二 步 : 定义 网 络 策略 清单 文件 (testing-netpol-denyall.yaml) ， 
将 testing 名 称 空间 的 入 站 及 出 站 的 默认 策略 修改 为 拒绝 访问 ， 并 再 一 次 
进行 访问 测试 : 





apiVersion: networking.k8s.io/vi 
kind: NetworkPolicy 


metadata: 
name: deny-all-traffic 
namespace: testing 
spec: 
podSselector: {} 
policyTypes: 
- Ingress 
- Egress 





接 下 来 ， 将 testing-netpol-denyall.yaml 定 义 的 默认 策略 deny-all-traffic 
予以 应 用 ， 为 testing 名 称 空间 设置 默认 的 网 络 策略 : 





$ kubectl1 apply -f testing-netpol-denyall.yaml 





回 到 第 一 步 创建 的 交互 式 客户 端 ， 再 次 对 nginx 和 myapp 发 起 访问 测 
试 。 为 了 避免 长 时 间 等 待 ， 这 里 为 curl 命 令 添加 --connect-timeout 选 项 为 
其 定义 连接 超时 时 长 。 由 下 面 的 命令 可 知 ， 此 时 无 法 再 访问 到 nginx 和 
myapp 的 相关 服务 : 





/# curl --connect-timeout 2 nginx.testing 
curl: (28) connect() timed out! 

/# curl --connect-timeout 2 myapp.testing 
curl: (28) connect() timed out! 

/ # 








第 三 步 : 定义 流量 放行 规则 配置 清单 nginx-allow-all.yaml， 放 行 
nginx Pod 之 上 80/TCP 端 口 的 所 有 流量 : 





apiVersion: networking.k8s.io/vi1 
kind: NetworkPolicy 
metadata: 
name: nginx-allow-all 
namespace: testing 
spec: 
podSelector: 
matchLabels: 
app: nginx 
ingress: 
- ports: 
- port: 80 
- from: 
- namespaceSelector: 
matchLabels: 
ns: kube-system 
egress: 
- to: 
policyTypes: 


- Ingress 
- Egress 





ara 


Re 定义 的 网 络 策略 应 用 至 集群 中 以 创建 相应 的 网 络 
末 哈 : 





~]$ kubect1l apply -f nginx-allow-all.yaml 





而 后 再 次 回 到 交互 式 测 试 客户 端 发 起 访问 请 求 进行 测试 ， 由 下 面 的 
命令 结果 可 知 ，nginx 已 经 能 够 正常 访问 ， 这 同时 也 意味 着 由 kube- 
system 名 称 空间 中 的 kube-dns 进 行 的 名 称 解析 服务 也 为 可 用 状态 : 





/# curl --connect-timeout 2 nginx.testing 





第 四 步 定义 网 络 策略 配置 清单 myapp-allow.yaml， 放 行 testing 名 
称 空间 中 来 自 nginx Pod 的 发 往 myapp Pod 的 80/TCP 的 访问 流量 ， 以 及 
myapp Pod 发 往 nginx Pod 的 所 有 流量 。 另 外 ， 人 允许 myapp Pod 与 kube- 
system 名 称 空 间 的 任何 Pod 进 行 交 互 的 所 有 流量 : 








apiVersion: networking.k8s.io/vi1 
kind: NetworkPolicy 
metadata: 
name: myapp-allow 
namespace: testing 
spec: 
podSelector: 
matchLabels: 
. app: myapp 
ingress: 
- from: 
- podSelector: 
matchLabels: 
app: nginx 
ports: 
- port: 80 
- from: 
- namespaceSelector: 
matchLabels: 
ns: kube-system 
egress: 
- to: 
- podSelector : 


matchLabels: 
app: nginx 
- to: 
- namespaceSelector: 
matchLabels: 
ns: kube-system 
policyTypes: 
- Ingress 
- Egress 





接 下 来 首先 创建 清单 中 定义 的 网 络 集 略 : 





~]$ kubect1l apply -f myapp-allow.yaml 
networkpolicy.networking.k8s.io "myapp-allow" configured 





而 后 切换 至 此 前 在 专用 终端 中 创建 的 临时 使 用 的 交互 式 Pod， 对 
myapp Pod 发 起 访问 请 求 。 由 下 面 的 命令 结果 可 知 ， 其 访问 被 拒绝 : 





# CUrl --connect-timeout 2 http://myapp.testing 
curl: (28) connect() timed out! 
/ # 





myapp Pod 仅 允许 来 自 nginx Pod 对 其 80/TCP 端 口 的 访问 ， 于 是 ， 这 
里 进入 testing 名 称 空间 中 的 是 nginx Pod 的 交互 式 接 口 ， 使 用 wget 命 令 对 
myapp Pod 发 起 访问 请 求 ， 如 下 面 的 命令 所 示 : 





~]$ kubectl exec -it nginx-b477df957-jb2nf -n testing -- /bin/sh 
/ # wget http://myapp.testing -0 - -q 

Hello MyApp | Version: vi | <a href="hostname.html">Pod Name</a> 
/ # 





需要 注意 的 是 ， 这 里 的 nginx Pod 经 由 Deployment 控 制 器 创建 ， 其 名 
称 格式 为 两 级 Hash 字 符 串 ， 读 者 在 执行 测试 操作 时 要 转换 为 实际 创建 的 
标识 符 。 如 果 所 有 测试 均 能 通过 ， 则 表示 网 络 策略 都 已 经 正常 生效 。 此 
示例 中 涉及 的 访问 控制 基本 上 能 够 类 比 到 大 多 数 场景 中 策略 设置 的 需 
求 ， 这 里 还 请 读者 细 细 撕 摩 其 设置 逻辑 。 


11.4 ”Calico 网 络 插 件 


Calico 是 一 个 开源 虚拟 化 网 络 方案 ， 用 于 为 云 原 生 应 用 实现 互联 及 
策略 控制 。 与 Flannel 相 比 ，Calico 的 一 个 显著 优势 是 对 网 络 策略 
(network policy〉 的 文 持 ， 它 允许 用 户 动 态 定义 ACL 规 则 控制 进出 容器 
的 数据 报 文 ， 实 现 为 Pod 间 的 通信 按 需 施加 安全 策略 。 事 实 上 ，Calico 可 
以 整合 进 大 多 数 主 流 的 编排 系统 ， 如 Kubernetes、Apache Mesos、 
Docker 和 OpenStack 等 。 


Calico 本 喘 是 一 个 三 层 的 虚拟 网 络 方案 ， 它 将 每 个 节点 都 当 作 路 由 
器 〈Iouter) ， 将 每 个 节点 的 容器 都 当 作 是 “节点 路 由 堪 ” 的 一 个 终端 并 
为 其 分 配 一 个 卫 地 址 ， 各 节点 路 由 器 通过 BGP (Border Gateway 
Protocol) 学 习 生 成 路 由 规则 ， 从 而 将 不 同 节 点 上 的 容器 连接 起 来 。 
此 ，Calico 方 案 其 实 是 一 个 纯 三 层 的 解决 方案， 通过 每 个 节点 协议 栈 的 
三 层 〈 网 络 层 ) 确保 容器 之 间 的 连通 性 ， 这 摆脱 了 flannel host-gw 类 型 
的 所 有 节点 必须 位 于 同一 二 层 网 络 的 限制 ， 从 而 极 大 地 扩展 了 网 络 规 模 
和 网 络 边 界 。 如 图 11-18 所 示 的 是 Calico 系 统 示意 图 。 
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图 11-18 ”Calico 系 统 示 意图 


BGP 是 互联 网 上 一 个 核心 的 去 中 心 化 自治 路 由 协议 ， 它 通过 维护 IP 
路 由 表 或 “前 级 ” 表 来 实现 自治 系统 (AS) 之 间 的 可 达 性 ， 属 于 矢量 路 由 
协议 。 不 过 ， 考 虑 到 并 非 所 有 的 网 络 都 能 支持 BGP， 以 及 Calico 控 制 平 
面 的 设计 要 求 物理 网 络 必须 是 二 层 网 络 ， 以 确保 vRouter 间 均 直 接 可 
达 ， 路 由 不 能 够 将 物理 设备 当 作 下 一 跳 等 原因 ， 为 了 文 持 三 层 网 络 ， 


Calico 还 推出 了 IP-in-IP 闭 加 的 模型 ， 它 也 使 用 Overlay 的 方式 来 传输 数 
据 。IPZPP 的 包头 非常 小 ， 而 且 也 是 内 置 在 内 核 中 ， 因 此 理论 上 它 的 速度 
要 比 VxLAN 快 一 点 ， 但 安全 性 更 差 。Calico 3.x 的 默认 配置 使 用 的 是 IPIP 
类 型 的 传输 方案 而 非 BGP。 





11.4.1 ”Calico 工 作 特 性 


Calico 利 用 Linux 内 核 在 每 一 个 计算 节点 上 实现 了 一 个 高 效 的 
vRouter( 虚 拟 路 由 器 〉 进行 报 文 转发 ， 而 每 个 vRouter 都 通过 BGP 负 责 
把 上 自身 所 属 的 节点 上 运行 的 Pod 资 源 的 外 地 址 信息 基于 节点 的 agent 程 序 

(Felix) 直接 由 vRouter 生 成 路 由 规则 向 整个 Calico 网 络 内 进行 传播 ， 不 
过 ， 尽 管 小 规模 部 晋 可 以 直接 互联 ， 但 大 规模 网 络 还 是 建议 使 用 BGP 路 
由 反射 器 (route reflector) 来 完成 。Felix 也 支持 在 每 个 节点 上 按 需 生成 
ACL (Access Control List) 从 而 实现 安全 策略 ， 如 隔离 不 同 的 租户 或 项 
目的 网 络 通信 。vRouter 利 用 BGP 通 告 本 节点 上 现 有 的 地 址 分 配 信 息 ， 
个 vRonuter 均 接 入 BGP 路 由 反射 器 以 实现 控制 平面 扩展 。 


Calico 承 载 的 各 Pod 资 源 直 接 通过 vRouter 经 由 基础 网 络 进行 互联 ， 
它 非 铬 加 、 无 隧道 、 不 使 用 VRF 表 ， 也 不 依 癌 于 NAT， 因 此 每 个 工作 负 
载 都 可 以 直接 配置 使 用 公 网 IP 接 入 互联 网 ， 当 然 ， 也 可 以 按 需 使 用 网 络 
策略 控制 它 的 网 络 连通 性 。 


(1) 经 IP 路 由 直 连 


Calico 中 ，Pod 收 发 的 耳 报 文 由 所 在 节点 的 Linux 内 核 路 由 表 负 贡 转 
发 ， 并 通过 iptables 规 则 实现 其 安全 功能 。 某 Pod 对 象 发 送 报 文 时 ， 
Calico 应 确保 节点 总 是 作为 下 一 跳 MAC 地 址 返回 ， 不 管 工作 负载 本 身 可 
能 配置 什么 路 由 ， 而 发 往 某 Pod 对 象 的 报 文 ， 其 最 后 一 个 卫 跃 点 就 是 Pod 
所 在 的 节点 ， 也 就 是 说 ， 报 文 的 最 后 一 程 即 由 节点 送 往 目 标 Pod 对 象 ， 
如 图 11-19 所 示 。 
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图 11-19 ”经 IP 路 由 直 连 


需 为 某 Pod 对 象 提供 连接 时 ， 系 统 上 的 专用 插件 〈 如 Kubernetes 的 
CNI) 负责 将 需求 通知 给 Calico Agent。 收 到 消息 后 ，Calico Agent 会 为 
每 个 工作 负载 添加 直接 路 径 信息 到 工作 负载 的 TAP 设 备 〈 如 veth) 。 而 


运行 于 当前 节点 的 BGP 客 户 端 监 控 到 此 类 消息 后 会 调用 路 由 reflector 回 
工作 于 其 他 节点 的 BGP 客 户 端 进 行 通告 。 


(2) 简单 、 高 效 、 易 扩展 


Calico 未 使 用 额外 的 报 文 封 节 和解 封 朔 ， 从 而 简化 了 网 络 拓扑 ， 这 
也 是 Calico 高 性 能 、 易 扩展 的 关键 因素 。 毕 竞 ， 小 的 报 文 减少 了 报 文 分 
片 的 可 能 性 ， 而 且 较 少 的 封装 和 解 封装 操作 也 降低 了 对 CPU 的 占用 。 此 
外 ， 较 少 的 封装 也 易于 实现 报 文 分 机 ， 易 于 进行 故障 排 答 。 


创建 、 移 动 或 删除 Pod 对 象 时 ， 相 关 路 由 信息 的 通告 速度 也 是 影响 
其 扩展 性 的 一 个 重要 因素 。Calico 出 色 的 扩展 性 缘 于 与 互联 网 架构 设计 
原则 别 无 二 致 的 方式 ， 它 们 都 使 用 了 BGP 作 为 控制 平面 。BGP 以 高 效 管 
理 百 万 级 的 路 由 设备 而 闻名 于 世 ，Calico 自 然 可 以 游 思 有 余地 适 配 大 型 
IDC 网 络 规 模 。 另 外 ， 由 于 Calico 各 工作 负载 使 用 基 IP 直 接 进行 互联 ， 
因此 它 还 支持 多 个 跨 地 域 的 IDC 之 间 进 行 协 同 。 


(3) 较 好 的 安全 性 


原则 上 ，Calico 网 络 允 许 IDC 中 的 任何 工作 负载 与 其 他 任意 目标 进 
行 通信 ， 但 管理 员 或 用 户 却 未 必 期 望 如 此 ， 在 多 租户 IDC 中 隔离 租户 网 
络 几乎 是 必然 之 需 。 于 是 ，Calico 操 纵 节 点 上 的 iptables 规 则 以 管控 工作 
负载 的 互联 许可 。 此 种 iptables 规 则 操纵 功能 是 节点 间 的 警戒 哨 ， 负 贡 阻 
挡 任 何 非 许可 流量 ， 并 防止 通过 工作 负载 危及 节点 自身 。 


:严格 的 域 间 流量 分 隔 : 运行 于 某 个 租户 虚拟 网 络 内 的 应 用 应 严禁 
访问 其 他 租户 的 应 用 ， 这 种 流量 分 隅 是 由 和 久 经 考验 的 Linux 内 核 中 的 
ACL 子 系统 予以 实现 的 。 


-精细 的 策略 规则 :实现 了 租户 间隔 离 的 网 络 方案 大 多 并 没有 额外 
实现 细 粒 度 的 安全 策略 ， 而 Calico 通 过 使 用 Linux 内 建 的 ACL 扩 展 来 支持 
一 众 安 全 规则 ， 任 何 可 由 ACL 文 持 的 功能 均 能 通过 Calico 实 现 。 


.简洁 而 不 简单 : Calico 直 接 使 用 了 网络， 无 须 任 何 地 址 转换 或 隧道 
承载 的 机 制 实 现 了 一 个 简洁 的 “WYSIWYG” (What You See Is What You 
Get) 网 络 模型 ， 它 可 以 清晰 地 标识 出 每 个 报 文 从 哪儿 来 ， 到 哪儿 去 。 
于 是 ， 管 理 员 可 因此 而 清晰 地 理解 流量 的 来 去 。 

















11.4.2 Calico 系 统 架 构 


概括 来 说 ，Calico 主 要 由 Felix、Orchestrator Plugin、etcd、BIRD 和 
BGP Router Reflector 等 组 件 组 成 ， 其 组 件 架 构 如 图 11-20 所 示 。 





图 11-20 ”Calico 系 统 组 件 





:Felix: Calico Agent， 运 行 于 每 个 节点 。 


“Orchestrator Plugin: 编排 系统 〈 如 Kubernetes、OpenStack 等 ) 以 将 
Calico 整 合 进 系统 中 的 插件 ， 例 如 Kubernetes 的 CNI。 


:etcd: 持久 存储 Calico 数 据 的 存储 管理 系统 。 
.BIRD: 用 于 分 发 路 由 信息 的 BGP 客 户 端 。 


.BGP Route Reflector: BGP 路 由 反射 器 ， 可 选 组 件 ， 用 于 较 大 规模 
的 网 络 场景 。 


1.Felix 


Felix 运 行 于 各 节点 的 用 于 支持 端点 《VM 或 Container) 构建 的 守护 
进程 ， 它 负责 生成 路 由 和 ACL， 以 及 其 他 任何 由 节点 用 到 的 信息 ， 从 而 


为 各 靖 反 构建 连接 机 制 。Felix 在 各 编排 系统 中 主要 负责 以 下 任务 。 


首先 是 接口 管理 〈Interface Management) 功能 ， 人 负责 为 接口 生成 必 
要 的 信息 并 送 往 内 核 ， 以 确保 内 核能 够 正确 处 理 各 端点 的 流量 ， 尤 其 是 
要 确保 各 节点 能 够 啊 应 目标 MAC 为 当前 节点 上 各 工作 负载 的 MAC 地 址 
的 ARP 请 求 ， 以 及 为 其 管理 的 接口 打开 转发 功能 。 另 外 ， 它 还 要 监控 各 
接口 的 变动 以 确保 规则 能 够 得 到 正确 的 应 用 。 


其 次 是 路 由 规划 (Route Programming) 功能 ， 其 负 贡 为 当前 节点 运 
行 的 各 端点 在 内 核 FHIB 〈EForwarding Information Base) 中 生成 路 由 信 
轧 ， 以 保证 到 达 当 前 节点 的 报 文 可 正确 转发 给 端点 。 


再 次 是 ACL 规 划 (ACL Programming) 功能 ， 负 贡 在 Linux 内 核 中 生 
成 ACL， 用 于 实现 仅 放行 端点 间 的 合法 流量 ， 并 确保 流量 不 能 绕 过 
Calico 的 安全 措施 。 


最 后 是 状态 报告 (State Reporting) 功能 ， 负 责 提供 网 络 健 康 状态 
的 相关 数据 ， 尤 其 是 报告 由 其 管理 的 节点 上 的 错误 和 问题 。 这 些 报告 数 
据 会 存储 于 etcd， 供 其 他 组 件 或 网 络 管理 员 使 用 。 


2. 编 排 系 统 插件 


编排 系统 插件 (Orchestrator Plugin) 依赖 于 编排 系统 目 身 的 实现 ， 
故此 并 不 存在 一 个 固定 的 插件 以 代表 此 组 件 。 编 排 系 统 插件 的 主要 功能 
是 将 Calico 整 合 进 系 统 中 ， 并 让 管理 员 和 用 户 能 够 使 用 Calico 的 网 络 功 
能 。 它 主要 负责 完成 API 的 转换 和 反馈 输出 。 


编排 系统 通常 有 其 自身 的 网 络 管理 API， 网 络 插件 需要 负责 将 对 这 
些 API 的 调用 转 为 Calico 的 数据 模型 并 存储 于 Calico 的 存储 系统 中 。 如 果 
有 必要 ， 网 络 插件 还 要 将 Calico 系 统 的 信息 反馈 给 编排 系统 ， 如 Felix 的 
存活 状态 ， 网 络 发 生 错 误 时 设 定 相应 的 端点 为 故障 等 。 


3.etcd 存 储 系统 


Calico 使 用 etcd 完 成 组 件 间 的 通信 ， 并 以 之 作为 一 个 持久 数据 存储 
系统 。 根 据 编排 系统 的 不 同 ，etcd 所 扮演 角色 的 重要 性 也 因 之 而 异 ， 但 
它 贯 守 了 整个 Calico 部 署 全 程 ， 并 被 分 为 两 类 主机 : 核心 集群 和 代理 
(proxy) 。 在 每 个 运行 着 Felix 或 编排 系统 插件 的 主机 上 都 应 该 运行 一 























个 etcd 代 理 以 降低 etcd 集 群 和 集群 边缘 节点 的 压力 。 此 模式 中 ， 每 个 运 
行 着 插件 的 节点 都 会 运行 着 etcd 集 群 的 一 个 成 员 节 点 。 


etcd 是 一 个 分 布 式 、 强 一 致 、 具 有 容错 功能 的 存储 系统 ， 这 一 点 有 
助 于 将 Calico 网 络 实现 为 一 个 状态 确切 的 系统 : 要 么 正常 ， 要 么 发 生 故 
障 。 另 外 ， 分 布 式 存储 易于 通过 扩展 应 对 访问 压力 的 提升 ， 而 避免 成 为 
系统 瓶 贷 。 男 外 ，etcd 也 是 Calico 各 组 件 的 通信 总 线 ， 可 用 于 确保 让 非 
etcd 组 件 在 键 空间 (keyspace) 中 监控 某 些 特定 的 键 ， 以 确保 它们 能 够 
看 到 所 做 的 任何 更 改 ， 从 而 使 它们 能 够 及 时 地 啊 应 这 些 更 改 。 


4.BGP 客 户 端 (BIRD ) 














Calico 要 求 在 每 个 运行 着 Felix 的 节点 上 同时 还 要 运行 一 个 BGP 客 户 
端 ， 负 责 将 Felix 生 成 的 路 由 信息 载 入 内 核 并 通告 到 整个 DC。 在 Calico 
语 境 中 ， 此 组 件 是 通用 的 BIRD， 因 此 任何 BGP 客 户 端 〈 如 GoBGP 等 ) 
都 可 以 从 内 核 中 提取 路 由 并 对 其 分 发 对 于 它们 来 说 都 适合 的 角色 。 


BGP 客 户 端 的 核心 功能 束 是 路 由 分 发 ， 在 Felix 插 入 路 由 信息 至 内 核 
FIB 中 时 ，BGP 客 户 逆 会 捕获 这 些 信息 并 将 其 分 友 至 其 他 市 皮 ， 从 而 确 
保 了 流量 的 高 效 路 由 。 


5.BGP 路 由 反射 器 (BIRD ) 


在 大 规模 的 部 署 场景 中 ， 简 易 版 的 BGP 客 户 端 易 于 成 为 性 能 瓶颈 ， 
因为 它 要 求 每 个 BGP 客 户 端 都 必须 连接 至 其 同一 网 络 中 的 其 他 所 有 BGP 
客户 端 以 传递 路 由 信息 ， 一 个 有 着 N 个 节点 的 部 署 环境 中 ， 其 存在 网 络 
连接 的 数量 为 N 的 二 次 方 ， 随 着 N 值 的 逐渐 增 大 ， 其 连接 复杂 度 会 急剧 
上 升 。 因 而 在 较 大 规模 的 部 署 场景 中 ，Calico 应 该 选择 部 署 一 个 BGP 路 
由 反射 器 ， 它 是 由 BGP 客 户 端 连接 的 中 心 点 ，BGP 的 点 到 点 通信 也 就 因 
此 转化 为 与 中 心 点 的 单 路 通信 模型 ， 如 图 11-18 所 示 。 出 于 元 余 之 需 ， 
生产 实践 中 应 该 部 晋 多 个 BGP 路 由 反射 器 。 对 于 Calico 来 说 ，BGP 客 户 
端 程序 除了 作为 客户 端 使 用 之 外 ， 还 可 以 配置 成 路 由 反射 器 。 




















11.4.3 Calico 部 署 要 点 











安装 Calico 需 要 事先 有 运行 中 的 Kubernetes 1.1 及 以 上 版 本 的 集群 ， 
如 果 要 用 到 网 络 策略 ， 则 Kubernetes 版 本 要 1.3.0 及 以 上 才 可 以 。 另 外 ， 
还 需要 一 个 可 由 Kubernetes 集 群 各 节点 访问 到 的 etcd 集 群 。 虽 然 可 以 让 
Calico 和 Kubernetes 共 同 使 用 同一 个 etcd 集 群 ， 然 则 有 些 场 景 中 推荐 为 
etcd 使 用 专用 集群 ， 如 需要 获得 较 好 的 性 能 时 。 


与 Kubernetes 集 群 进行 整合 时 ，Calico 需 要 提供 三 个 组 件 ， 上 有 具 体 如 








:calico/node: Calico 于 Kubernetes 集 群 中 为 每 个 节点 上 运行 的 容器 提 
供 Felix Agent 和 BGP 客 户 端 。 


:cni-plugin: CNI 网 络 插件 ， 用 于 整合 Calico 和 kubelet， 发 现 Pod 资 
源 ， 并 将 其 添加 进 Calico 网 络 ， 因 此 ， 每 个 运行 kubelet 的 主机 都 需要 配 
置 。 


:Calico/kube-controllers: Calico 网 络 策略 控制 器 。 


Calico 的 安装 有 两 种 方式 ， 一 是 配置 其 独立 运行 于 Kubernetes 集 群 之 
外 ， 但 calico/kube-controllers 依 然 需 要 以 Pod 资 源 运 行 于 集群 之 上 。 男 一 
种 是 以 插件 方式 配置 Calico 完 全 托管 运行 于 Kubernetes 集 群 之 上 ， 不 过 此 
种 方式 要 求 Kubernetes 版 本 至 少 在 1.4.0 以 上 。 


另外 ，Calico 以 Kubernetes 插 件 方 式 部 署 的 实现 方式 有 两 种 ， 一 是 标 
准 托管 式 部 晋 ， 即 Calico 使 用 专用 的 etcd 存 储 管理 数据 持久 化 及 组 件 间 
的 通信 。 另 一 个 是 以 Kubernetes API Server 为 Datastore， 调 用 Kubernetes 
的 API 完 成 所 需 的 操作 。 目 3.0 版 本 起 ，Calico 官 方 推荐 使 用 第 二 种 方 
ee 所 推荐 的 则 是 第 一 种 部 署 
Ts 


再 者 ，Calico 既 可 以 单独 为 Kubernetes 系 统 提 供 网 络 服务 及 网 络 策 
略 ， 也 可 以 与 flannel 整 合 在 一 起 由 flannel 实 现 网 络 服务 而 Calico 仅 提供 网 
络 策 略 。 事 实 上 ， 还 有 一 个 本 身 即 是 将 flannel 或 Calico 合 二 为 一 的 解决 
方案 Canal， 不 过 ， 这 已 经 是 男 一 个 独立 的 项 目 。 





需要 注意 的 是 ，Calico 分 配 的 地 址 池 与 Kubernetes 集 群 的 --pod- 
network-cidr 的 值 应 该 保持 一 致 ， 默 认 情 况 下 ，Calico 的 配置 清单 中 使 用 
192.168.0.0/16 作 为 Pod 网 络 。 不 过 ， 如 末 用 户 计 划 将 Calico 和 flannel 协 同 
进行 部 署 ， 则 可 以 在 此 前 已 有 flannel 插 件 的 基础 上 直接 添加 Calico。 
11.4.4 节 将 在 讲解 独立 部 署 Calico 的 同时 提供 网 络 服务 及 网 络 策略 ， 协 同 
fannel 的 部 署 方式 请 读者 参考 官方 文件 中 的 相关 介绍 进行 操作 。 





11.4.4” ”部署 Calico 提 供 网 络 服务 和 网 络 策略 


为 了 便于 简化 部 辕 环 境 及 操作 复杂 上 度 ， 本 厄 的 操作 建立 在 一 个 刚 由 
kubeadm 部 署 完成 的 新 的 Kubernetes 集 群 之 上， 部 署 时 为 --pod-network- 
cidr 选 项 指定 了 使 用 192.168.0.0/16 网 络 以 适 配 Calico 的 默认 网 络 配置 ， 它 
还 没有 添加 过 任何 网 络 插件 。Calico 的 部 署 方式 极其 灵活 ， 这 里 难以 尽 
述 其 所 有 的 实现 方式 ， 仅 以 典型 应 用 场景 对 其 加 以 说 明 。 


Calico 3 目前 仅 支 持 Kubernetes 1.8 及 其 之 后 的 版 本 ， 并 且 它 要 求 使 
用 一 个 能 够 被 各 组 件 访问 到 的 键 值 存 储 系 统 ， 在 Kubernetes 环 境 中 ， 可 
用 的 选择 有 etcd v3 或 Kubernetes API 数 据 存储 。 本 部 署 示例 会 将 
Kubernetes API 作 为 Calico 的 数据 存储 取代 etcd， 这 也 是 在 本 章 写 作 时 时 
下 最 新 的 稳定 版 本 Calico 3 版 本 中 推荐 的 配置 。 男 外 ，Calico 3 目前 对 
ee ipvs 模 式 的 支持 尚且 处 于 试用 级 别 ， 因 此 不 建议 读者 在 生产 
环境 用 。 

















O 注意 ”不同 版 本 的 Calico 的 部 黎 方 式 可 能 不 尽 相 同 ， 读 者 般 
要 根据 操作 时 的 有 具体 情况 参考 官方 文档 来 确定 具体 的 部 车 方案 及 部 着 步 


又。 


在 启用 了 RBAC 的 Kubernetes 集 群 部 车 Calico 时 ， 需 要 先 创 建 必要 的 
ClusterRole 和 ClusterRoleBinding 资 源 。Calico 官 方 给 出 了 标准 定义 的 配 
置 清 单 ， 部 署 时 ， 直 接应 用 在 线 清 单 即 可 ， 如 下 面 的 命令 所 示 : 











~]$ kubect1 apply -f https://docs.projectcalico.org/v3.2/getting-started/kubernetes, 
installation/hosted/rbac-kdd.yaml 





应 用 完成 后 ， 它 会 创建 名 为 calico-node 的 clusterrole 和 
clusterrolebinding， 为 相关 的 Pod 资 源 calico-node 的 ServiceAccount 授 予 必 
要 的 资源 管理 权限 。Kubernetes 集 群 规 模 小 于 50 节 点 时 ， 可 以 类 似 如 下 
命令 部 署 Calico 的 各 相关 组 件 ， 它 们 会 创建 多 个 标准 的 Kubernetes 资 源 及 
数 个 目 定 义 的 资源 : 





~]$ kubect1 apply -f https://docs.projectcalico.org/v3.2/getting-started/kubernetes, 


installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml 





可 通过 如 下 命令 查看 calico-node 相 关 的 Pod 资 源 于 各 节点 中 的 部 署 
状态 。 待 所 有 Pod 资 源 均 处 于 “Running” 状 态 后 ， 即 可 正常 使 用 其 相关 的 








~]$ kubect1 get pods -1 k8s-app=calico-node -o wide -n kube-system 





工作 于 IPIP 模 式 的 Calico 会 在 每 个 节点 上 创建 一 个 tunl0 接 口 (TUN 
类 型 虚拟 设备 ) 用 于 封装 三 层 隧 道 报 文 。 节 点 上 创建 的 每 一 个 Pod 资 
源 ， 都 会 由 Calico 上 自动 创建 一 对 虚拟 以 太 网 接口 (TAP 类 型 的 虚拟 设 
备 ) ， 其 中 一 个 附加 于 Pod 的 网 络 名 称 空间 ， 另 一 个 “名称 以 cali 为 前 组 
后 跟随 机 字 串 ) 留置 在 节点 的 根 网 络 名 称 空间 ， 并 经 由 tunl0 封 装 或 解 封 
三 层 隧道 报 文 。Calico IPIP 模 式 如 图 11-21 所 示 。 








iplp tunnel 























Node Node 
图 11-21 Calico IPIP 


部 署 完成 后 ，Calico 会 在 每 个 节点 上 生成 到 达 Kubernetes 集 群 中 每 个 
市 感 上 的 Pod 子 网 的 路 由 信息 ， 下 面 所 示 的 路 由 信息 是 部 蜀 示 例 中 
node01 主 机 上 生成 的 路 由 条 目 ， 它 们 由 各 节点 上 的 BIRD 以 点 对 点 的 方 
式 回 网 络 中 的 其 他 节点 进行 通告 并 学 习 其 他 布点 的 通告 而 得 : 





192.168.0.0/24 via 172.16.0.70 dev tunl10 proto bird onlink 
blackhole 192.168.1.0/24 proto bird 

192.168.2.0/24 via 172.16.0.67 dev tunl10 proto bird onlink 
192.168.3.0/24 via 172.16.0.68 dev tunl10 proto bird onlink 





在 每 个 节点 上 创建 Pod 资 源 时 ， 由 Calico CNI 插 件 为 其 生成 TAP 设 备 
并 分 配 地 址 后 ， 也 会 在 节点 的 网 络 名 称 空间 中 生成 一 个 新 的 路 由 条 目 ， 
UU 它 指明 了 发 往 本 节点 上 某 特定 Pod IP 的 报 文 应 该 经 由 的 
TAP 接 口 : 








192.168.1.3 dev cali8bbo5ff8b64 scope link 





在 集群 中 部 署 一 些 Pod 资 源 即 可 完成 集群 网 络 连 接 测 试 。 假 设 此 时 
在 node01 上 存在 一 个 IP 地 址 为 192.168.1.3 的 Pod A， 以 及 在 node02 上 存在 
一 个 了 地址 为 192.168.2.4 的 PodB， 通 过 Pod A 的 交互 式 接口 对 Pod B 发 起 
ping 请 求 ， 在 node01 的 物理 接口 上 以 root 用 户 的 身份 抓 取 通信 报 文 ， 命 
令 及 截取 的 一 次 通信 的 往返 结果 示例 如 下 : 





~]# tcpdump -i ens33 -nn ip host 172.16.0.66 and host 172.16.0.67 

10:58:03.553589 IP 172.16.0.66 > 172.16.0.67: IP 192.168.1.3 > 192.168.2.4: ICMP 
echo request, id 4096, seq 33, length 64 (ipip-proto-4) 

10:58:03.553883 IP 172.16.0.67 > 172.16.0.66: IP 192.168.2.4 > 192.168.1.3: ICMP 
echo reply, id 4096, seq 33, length 64 (ipip-proto-4) 





命令 结果 显示 ，Pod 间 的 通信 经 由 IPIP 的 三 层 隧 道 转发 ， 外 层 IP 首 
部 中 的 IP 地 址 为 通信 双方 的 节点 IP (172.16.0.66 和 172.16.0.67) ， 内 层 IP 
首部 中 的 IP 地 址 为 通信 双方 的 Pod IP (192.168.1.3 和 192.168.2.4) 。 相 比 
较 VxLAN 的 二 层 隧 道 来 说 ，IPIP 隧 道 的 开销 较 小 ， 但 其 安全 性 也 更 差 一 


些 。 








需要 提醒 读者 注意 的 是 ，tunl0 接 口 的 MTU 默 认为 1440， 这 种 设置 
主要 是 为 适 配 Google 的 GCE 环 境 ， 在 非 GCE 的 物理 环境 中 ， 其 最 佳 值 为 
1480。 因 此 ， 对 于 非 GCE 环 境 的 部 署 ， 建 议 将 配置 清单 calico.yaml 下 载 
至 本 地 修改 后 ， 再 将 其 应 用 到 集群 中 。 要 修改 的 内 容 是 DaemonSet 资 源 
calico-node 的 Pod 模 板 ， 将 容器 calico-node 的 环境 变 
量 “FELIX_INPUTMTU” 的 值 修 改 为 1480 即 可 ， 类 似 如 下 所 示 。 图 11-22 
给 出 了 Calico 部 署 于 不 同 网 络 环境 时 不 同 部 署 方式 适用 的 MTU 大 小 。 


Network MTU Calico MTU Calico MTU with IP-in-IP | Caalico MTU with VxLAN (IPv4) 


9000 9000 8980 8950 
1460 (GCE) 1460 1440 1410 
9001 (AWS Jumbo) 9001 8981 8951 


图 11-22 Calico 于 各 网 络 环境 上 适用 的 MTU 


对 于 50 个 节点 以 上 规模 的 集群 来 说 ， 所 有 Calico 节 点 均 基 于 
Kubernetes API 存 取 数 据 会 为 API Server 种 来 不 小 的 通信 压力 ， 这 就 应 该 
使 用 calico-typha 进 程 将 所 有 Calico 的 通信 集中 起 来 与 API Server 进 行 统一 
交互 。calico-typha 以 Pod 资 源 的 形式 托管 运行 于 Kubernetes 系 统 之 上 ， 启 
用 的 方法 为 下 载 前 面 步骤 中 用 到 的 Calico 的 部 署 清单 文件 至 本 地 ， 修 改 
其 calico-typha 的 Pod 资 源 副 本 数量 为 所 期 望 的 值 并 重新 应 用 配置 清单 即 
可 : 














apiVersion: apps/v1betal 
kind: Deployment 
metadata: 

name: calico-typha 
spec: 


replicas: <number of replicas> 





每 个 calico-typha Pod 资 源 可 承载 100 到 200 个 Calico 节 点 的 连接 请 
最 多 不 要 超过 200 个 。 另 外 ， 整 个 集群 中 的 calico-typha 的 Pod 资 源 总 
量 不 要 超过 20 个 。 








数 尽 


11.4.5 客户 端 工 具 calicoctl 


Calico 的 二 进 制 程序 文件 calicoct 可 直接 操作 Calico 存 储 来 得 看 、 修 
改 或 配置 Calico 系 统 特 性 ， 它 可 以 运行 为 Kubernetes 系 统 之 上 的 Pod 资 
源 ， 也 可 直接 以 裸 二 进 制 文件 部 晋 于 某 管理 主机 之 上 ， 例 如 ，kubectl 所 
在 某 主 机 以 root 用 户 的 身份 下 载 calicoct 文件 并 直接 保存 于 /usrbin/ 目 
录 中 : 








~]# wget https://github.com/projectcalico/calicoctl/releases/download/v3.1.1/calicorc 
-0 /usr/bin/calicoctl 
~]# chmod +x /usr/bin/calicoctl 





calicoctl 通 过 读 写 Calico 的 数据 存储 系统 (datastore〉 进行 查看 或 进 
行 各 类 管理 操作 ， 通 常 ， 它 需要 提供 认证 信息 经 由 相应 的 数据 存储 完成 
认证 。 使 用 Kubernetes API 数 据 存储 时 ， 需 要 使 用 类 似 kubectl 的 认证 信 
居 完 成 认证 。 它 可 以 通过 环境 变量 声明 的 DATASTORE_TYPE 和 和 
KUBECONFIG 接 入 Kubernetes 集 群 ， 例 如 以 如 下 命令 格式 运行 
calicoct]: 





~]$ DATASTORE_TYPE=kubernetes KUBECONFIG=~/ ,kube/config calicoctl get nodes 





也 可 以 直接 将 认证 信息 等 保存 于 配置 文件 中 ，calicoctl 默 认 加 
载 /etc/calico/calicoctl.cfg 配 置 文件 读 取 配置 信息 。 配 置 文件 为 yaml 格 
式 ， 话 法 极其 类 似 于 Kubernetes 的 资源 配置 清单 : 





apiVersion: projectcalico.org/v3 
kind: CalicoAPIConfig 
metadata: 
spec: 
datastoreType: "kubernetes" 
kubeconfig: "/PATH/TO/.kube/config" 





将 上 面 示例 配置 中 的 /PATH/TO 路 径 修 改 为 相应 的 用 户 家 目录 即 
可 ， 如 /home/ik8s/。 当 然 ， 也 可 以 是 用 户 自 定义 的 其 他 kubeconfig 配 置 
文件 的 存放 路 径 。 


calicoctl 的 通用 语法 格式 为 “calicoctl[options]<command> 
[<args>...]”"， 它 有 着 多 个 子 命令 ， 用 于 增删 改 查 相应 的 配置 及 状态 信息 
和 等。 例如， 可 使 用 如 下 命令 查看 当前 Calico 部 署 的 相关 节点 状态 信息 : 














~]$calicoctl node status 





默认 情况 下 ，Calico 的 BGP 网 络 工作 于 点 对 点 的 网 格 (node-to-node 
mesh) 模型 ， 它 仅 适 用 于 较 小 规模 的 集群 环境 。 中 级 集群 环境 应 该 使 用 
全 局 对 等 BGP 模 型 (Global BGP peers) ， 以 在 同一 二 层 网 络 中 使 用 一 
个 或 一 组 BGP 有 反射 器 构建 BGP 网 络 环境 。 而 大 型 集群 环境 需要 使 用 每 市 
点 对 等 BGP 模 型 (Per-node BGP peers) ， 即 分 布 式 BGP 反 射 器 模型 ， 一 
个 典型 的 用 法 是 将 每 个 节点 都 配置 为 自 带 BGP 反 射 器 接 入 机 加 顶部 交换 
机 上 的 路 由 反射 器 。 


另外 ， 读 者 也 可 以 通过 如 下 命令 了 解 Calico 当 前 下 地 址 池 的 相关 设 
定 ， 包 括 其 地 址 范围 ， 是 否 启用 了 IPIP 模 型 等 : 








~]$ calicoct1 get ipPool -0 yaml 
apiVersion: projectcalico.org/v3 
items: 
- apiVersion: projectcalico.org/v3 
kind: IPPooJ 
metadata: 
spec: 
cidr: 192.168.0.0/16 
ipipMode: Always 
natoutgoing: true 





事实 上 ， 仪 在 那些 不 支持 用 户 自 定义 BGP 配 置 的 网 络 中 才 需 要 使 用 
IPIP 的 隧道 通信 类 型 。 如 有 果 读 者 有 一 个 自主 可 控 的 网 络 环境 且 部 署 规模 
较 大 时 ， 可 以 考虑 启用 BGP 的 通信 类 型 降低 网 络 开 销 以 提升 传输 性 能 ， 
并 且 应 该 部 普 BGP 反 射 器 来 提高 路 由 学 习 效率 。 有 具体 的 实现 方式 请 参考 
Calico 站 点 上 https://docs.projectcalico.org 给 出 的 文档 。 





11.5 本章 小 结 


本 章 详 细 描 述 了 Kubernetes 的 网 络 模型 、CNI 插 件 体 系 、 主 流 的 CNI 
插件 flannel 和 Calico， 并 重点 介绍 了 flannel 和 Calico 的 特性 和 应 用 方式 ， 
具体 如 下 。 


:Kubernetes 的 网 络 模型 中 包含 容器 间 通 信 、Pod 间 通信 、Service 与 
Pod 间 的 通信 ， 以 及 集群 外 部 流量 与 Pod 间 的 通信 四 种 通信 需求 。 


.Kubermetes 网 络 模型 的 实现 通过 CNI 接 口 由 外 部 网 络 插件 来 实现 ， 
如 flannel、Calico 和 Canal 等 。 


-flannel 支 持 host-gw、VxLAN 和 UDP 等 后 端 ， 默 认为 VxLAN。 


:网络 策 略 能 够 给 为 Pod 间 提供 通信 隔离 机 制 ， 它 支持 ingress 和 
Egress 两 种 类 型 的 规则 。 

:Calico 是 另 一 个 流行 的 网 络 插件 ， 它 提供 了 高 性 能 的 适用 于 大 规模 
网 络 模型 的 虚拟 网 络 。 


第 12 章 ”Pod 资源 调度 


API Server 接 受 客户 端 提 交 Pod 对 象 创建 请 求 后 的 操作 过 程 中 ， 有 一 
个 重要 的 步骤 是 由 调度 器 程序 (kube-scheduler) 从 当前 集群 中 选择 一 个 
可 用 的 最 佳节 点 来 接收 并 运行 它 ， 通 常 是 默认 的 调度 器 〈default- 
scheduler) 负责 执行 此 类 任务 。 对 于 每 个 待 创建 的 Pod 对 象 来 说 ， 调 度 
过 程 通 稼 分 为 三 个 阶段 一 预选 、 优 选 和 选 定 三 个 步骤 ， 以 筛选 执行 任务 
的 最 佳节 点 。 本 章 将 重点 描述 这 三 个 步骤 的 工作 过 程 。 





12.1 Kubernetes 调 度 器 概述 


Kubernetes 系 统 的 核心 任务 在 于 创建 客户 端 请 求 创建 的 Pod 对 象 并 确 
保 其 以 期 望 的 状态 运行 。 创 建 Pod 对 象 时 ， 调 度 器 (scheduler) 负责 为 
每 一 个 未 经 调度 的 Pod 资 源 、 基 于 一 系列 的 规则 集 从 集群 中 挑选 一 个 合 
适 的 节点 来 运行 它 ， 因 此 它 也 可 以 称 作 Pod 调 度 器 。 调 度 过 程 中 ， 调 度 
右 不 会 修改 Pod 资 源 ， 而 是 从 中 读 取 数 据 ， 并 根据 配置 的 策略 挑选 出 最 
适合 的 节点 ， 而 后 通过 API 调 用 将 Pod 绑 定 至 挑选 出 的 节点 之 上 以 完成 调 
度 过 程 ， 如 图 12-1 所 示 。 


( pod 一 一 > \ nodeX | 


ee Scheduler | | 
node list 


图 12-1 Kubernetes 调 度 器 


Kubernetes 内 建 了 适合 绝 大 多 数 场 景 中 Pod 资 源 调度 需求 的 默认 调度 
器 ， 它 文 持 同时 使 用 算法 基于 原生 及 可 定制 的 工具 来 选 出 集群 中 最 适合 
运行 当前 Pod 资 源 的 一 个 节点 ， 其 核心 目标 是 基于 资源 可 用 性 将 各 Pod 资 
源 公平 地 分 布 于 集群 节点 之 上 。 目 前 ,平台 提供 的 默认 调度 器 也 称 
为 “通用 调度 器 ”， 它 通过 三 个 步骤 完成 调度 操作 : 市 点 预选 
(Predicate) 、 节 点 优先 级 排序 (Priority) 及 节点 择优 (Select) ， 如 
图 12-2 所 示 。 


( Pod ) 














_ neds 
node2 CS | 


| | | Predicate | 1 Priority | | Select eT 
node3 广 一 node3 -| nodel —————— node4 | 
























































图 12-2 ”节点 预选 、 优 选 及 选 定 示意 图 


1) 节点 预选 ， 基于 一 系列 预选 规则 (如 PodFitsResources 和 
MatchNode-Selector 等 ) 对 每 个 节点 进行 检查 ， 将 那些 不 符合 条 件 的 节 


2) 节点 优选 : 对 预选 出 的 节点 进行 优先 级 排序 ， 以 便 选 出 最 适合 
运行 Pod 对 象 的 节点 。 


3) 从 优先 级 排序 结果 中 挑 出 优先 级 最 高 的 市 点 运行 Pod 对 象 ， 当 此 
类 节点 多 于 一 个 时 ， 则 从 中 随机 选择 一 个 。 


偶尔 ， 有 些 特殊 的 Pod 资 源 需 要 运行 在 特定 的 节点 之 上， 或 者 说 对 
某 类 节点 有 着 特 殊 偏 好 (如 那些 有 着 SSD、GPU 等 特殊 硬件 的 节点 )， 
以 便 更 好 地 [匹配 容器 应 用 的 运行 需求 。 男 外 ， 有 的 Pod 资 源 与 其 他 Pod 资 
源 存在 着 特定 的 关联 性 ， 它 们 运行 于 同一 节点 以 便 能 够 实现 更 高 效 的 协 
同 效果 等 。 此 种 场景 可 通过 组 合 节 点 标签 ， 以 及 Pod 标 签 或 标签 选择 器 
等 来 激活 特定 的 预选 策略 以 完成 高 级 调度 ， 如 MatchInterPodAffinity、 
MatchNodeSelector 和 PodToleratesNodeTaints 等 预选 策略 ， 它 们 用 于 为 用 
户 提供 自 定义 Pod 亲 和 性 或 反 亲 和 性 、 节 点 亲 和 性 以 及 基于 污点 及 容忍 
度 的 调度 机 制 |。 


不 过 ， 未 激活 特定 的 预选 策略 时 ，Pod 资 源 对 节点 便 没有 特殊 偏 
好 ， 相 关 的 预选 集 略 无 法 在 节 扣 预选 过 程 中 真正 发 挥 作用 。 























12.1.1 第 用 的 预选 傈 上 略 


简单 来 说 ， 预 选 策略 就 是 节点 过 滤器 ， 例 如 节点 标签 必须 能 够 匹配 
到 Pod 资 源 的 标签 选择 器 〈 由 MatchNodeSelector 实 现 的 规则 ) ， 以 及 Pod 
容器 的 资源 请 求 量 不 能 大 于 节点 上 剩余 的 可 分 配 资源 (由 
PodFitsResources 实 现 的 规则 ) 等 。 执 行 预选 操作 时 ， 调 度 器 将 对 每 个 节 
点 基于 配置 使 用 的 预选 策略 以 特定 次 序 逐 一 科 查 ， 并 根据 一 票 否 决 制 进 
行 节点 淘汰 。 若 预选 后 不 存在 任何 一 个 满足 条 件 的 节点 ， 则 Pod 被 置 于 
Pending 状 态 ， 直 到 至 少 有 一 个 节点 可 用 为 止 。 目 前 ，Kubernetes 1.10 文 
持 的 预选 策略 如 图 12-3 所 示 。 

















Predicates Ordering 


加 default Predicates 





图 12-3 ”Kubernetes 的 预选 策略 


1) CheckNodeCondition: 检查 是 否 可 以 在 节点 报告 磁盘 、 网 络 不 
可 用 或 未 准备 好 的 情况 下 将 Pod 对 象 调 度 于 其 上 。 


2) HostName: 若 Pod 对 象 拥有 spec.hostname 属 性 ， 则 检查 节点 名 称 
字符 串 与 此 属性 值 是 否 匹 配 。 


3) PodFitsHostPorts: 和 若 Pod 容 器 定义 了 ports.hostPort 必 性， 则 检 碍 
其 值 指定 的 端口 是 否 已 被 节点 上 的 其 他 容器 或 服务 占用 。 在 Kubernetes 
1.0 版 本 之 前 此 预选 策略 名 称 为 PodFitsPorts。 


4) MatchNodeSelector: 知 Pod 对 象 定 义 了 spec.nodeSelector 必 性， 
则 检查 节点 标签 是 否 能 匹配 此 属性 值 。 


5) NoDiskConflict: 检查 Pod 对 象 请 求 的 存储 卷 在 此 节点 是 否 可 
用 ， 若 不 存在 冲突 则 通过 检查 。 


6) PodFitsResources: 检查 节点 是 否 有 足够 的 资源 (如 CPU、 内 存 
和 GPU 等 ) 满足 Pod 对 象 的 运行 需求 。 节 点 声明 其 资源 可 用 容量 ， 而 Pod 
则 定义 其 资源 需求 ， 于 是 ， 调 度 器 会 判断 节点 是 侣 有 足够 的 可 用 资源 运 
行 Pod 对 象 ， 知 无 法 满足 则 返回 失败 原因 【〈 例 如 ，CPU 或 内 存 资源 不 足 
等 ) 。 调 度 器 评判 资源 消耗 的 标准 是 厄 点 已 分 配 的 资源 量 〈( 各 容器 的 
requests 值 之 和 ) ， 而 非 其 上 各 Pod 对 象 已 用 的 资源 量 。 注 意 ， 那 些 在 注 
解 中 标记 为 关键 性 (critical〉 的 Pod 资 源 不 受 此 预选 策略 控制 。 


7) PodToleratesNodeTaints: 奉 Pod 对 象 定 义 了 spec.tolerations 属 
性 ， 则 检 碍 其 值 是 否 能 够 接纳 节点 定义 的 污点 (taints) ， 不 过 ， 它 仅 关 
注 上 具有 NoSchedule 和 NoExecute 两 个 效用 标识 的 污点 。 




















8) PodToleratesNodeNoExecuteTaints: 知 Pod 对 象 定 义 了 
spec.tolerations 属 性 ， 则 检查 其 值 是 否 能 够 接纳 节点 定义 的 NoExecute 类 
型 的 污点 。 


9) CheckNodeLabelPresence: 仪 检查 节点 上 指定 的 所 有 标签 的 存在 
性 ， 要 检查 的 标签 以 及 其 可 否 存 在 取决 于 用 户 的 定义 。 当 集群 中 部 署 的 
节点 以 regions/zones/racks 的 拓扑 方式 放置 旦 基于 此 类 标签 对 其 进行 位 置 
标识 时 ， 预 选 策 略 可 以 根据 此 类 标识 将 Pod 资 源 调 度 至 此 类 节点 之 上 。 


10) CheckServiceAffinity: 根据 当前 Pod 对 象 所 属 的 Service 已 有 的 











其 他 Pod 对 象 所 运行 的 节点 进行 调度 ， 其 目的 在 于 将 相同 Service 的 Pod 对 
象 放置 在 同一 个 或 同一 类 节点 上 以 提高 效率 。 此 预选 策略 试图 将 那些 在 
其 节点 选择 器 中 带 有 特定 标签 的 Pod 资 源 调度 至 拥有 同样 标签 的 节点 之 
上 ， 具 体 的 标签 则 取决 于 用 户 的 定义 。 例 如 ， 辱 某 Service 的 第 一 个 Pod 
有 一 个 节点 选择 器 rack， 而 且 它 被 调度 到 了 标签 为 region=rack 的 节点 ， 
则 属于 此 Service 的 所 有 其 他 后 续 的 Pod 对 象 都 将 被 调度 至 具有 相同 标签 
(region=rack)〉 的 节点 上 。 知 该 Pod 未 在 其 节点 选择 器 中 指定 标签 ， 则 
第 一 个 Pod 将 根据 可 用 性 放置 在 任 一 节点 之 上 ， 而 后 该 Service 的 所 有 后 
续 Pod 对 象 都 将 调度 至 与 该 节点 拥有 相同 标签 值 的 节点 上 。 


11) MaxEBSVolumeCount: 检查 节点 上 已 挂 载 的 EBS 存 储 卷 数量 是 
个 超过 了 设置 的 最 大 值 ， 默 认 值 为 39。 


12) MaxGCEPDVolumeCount: 检查 节点 上 已 挂 载 的 GCE PD 存储 
卷 数 量 是 否 超过 了 设置 的 最 大 值 ， 默 认 值 为 16。 


13) MaxAzureDiskVolumeCount:， 检查 节点 上 已 挂 载 的 Azure Disk 
存储 卷 数 量 是 否 超过 了 设置 的 最 大 值 ， 默 认 值 为 16。 


14) CheckVolumeBinding: 检查 节点 上 已 绑 定 和 未 绑 定 的 PVC 是 否 
能 够 满足 Pod 对 象 的 存储 卷 需求 ， 对 于 已 绑 定 的 PVC， 此 预选 策略 将 检 
查 给 定 的 节点 是 否 能 够 兼容 相应 的 PV， 而 对 于 未 绑 定 的 PVC， 预 选 策 
略 将 搜索 那些 可 满足 PVC 申 请 的 可 用 PV， 并 确保 它 可 与 给 定 的 节点 兼 
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容 。 
































15) NoVolumeZoneConflict 在 给 定 了 区 域 “zone) 限制 的 前 提 
下 ， 检 碍 在 此 节点 上 部 署 Pod 对 象 是 否 存在 存储 卷 冲 突 。 某 些 存储 卷 存 
在 区 域 调度 约束 ， 于 是 ， 此 类 存储 卷 的 区 域 标签 (zone-labels) 必须 与 
节点 上 的 区 域 标签 完全 匹配 方 可 满足 绑 定 条 件 。 


16) CheckNodeMemoryPressure: 知 给 定 的 节点 已 经 报告 了 存在 内 
存 资源 压力 过 大 的 状态 ， 则 检查 当前 Pod 对 象 是 否 可 调度 至 此 节点 之 
上 。 目 前 ， 最低 优先 级 的 BestEffort QoS 类 型 的 Pod 资 源 也 不 可 调度 至 此 
类 节点 之 上 ， 因 为 它们 随时 可 能 因 OOM 而 终止 。 





























17) CheckNodePIDPressure: 若 给 定 的 节点 已 经 报告 了 存在 PID 资 
源 压力 过 大 的 状态 ， 则 检查 当前 Pod 对 象 是 否 可 调度 至 此 节点 之 上 。 








18) CheckNodeDiskPressure: 知 给 定 的 节点 已 经 报告 了 存在 磁盘 资 
源 压力 过 大 的 状态 ， 则 检查 当前 Pod 对 象 是 否 可 调度 至 此 节点 之 上 。 


19) MatchInterPodAffinity: 检查 给 定 节点 是 否 能 够 满足 Pod 对 象 的 
亲 和 性 或 反 亲 和 性 条 件 ， 以 用 于 实现 Pod 亲 和 性 调度 或 反 亲 和 性 调度 。 


如 上 给 定 的 各 预选 策略 中 ，CheckNodeLabelPresence 和 
CheckServiceAffinity 可 以 接受 特定 的 配置 参数 以 便 在 预选 过 程 中 融合 用 
户 自 定义 的 调度 逻辑 ， 这 类 策略 也 可 称 为 可 配置 策略 ， 而 余下 那些 不 可 
接受 配置 参数 的 策略 也 统一 称 为 静态 策略 。 另 外 ，NoDiskConflict、 
PodToleratesNodeNoExecuteTaints、CheckNodeLabelPresence 和 
CheckServiceAffinity 没 有 包含 在 默认 的 预选 策略 中 。 














12.1.2 ”各 用 的 优选 函数 


预选 策略 旬 选 并 生成 一 个 节点 列表 后 即 进入 第 二 阶段 的 优选 过 程 。 
在 这 个 过 程 中 ， 调 度 器 向 每 个 通过 预选 的 节点 传递 一 系列 的 优选 函数 
(如 BalancedResourceAllocation 和 TaintTolerationPriority 等 ) 来 计算 其 优 
先 级 分 值 ， 优 先 级 分 值 介 于 0 到 10 之 间 ， 其 中 0 表示 不 适用 ，10 表 示 最 适 
合 托管 该 Pod 对 象 。Kubernetes 文 持 的 优选 函数 如 图 12-4 所 示 。 


default Priorities 





图 12-4 ”Kubemetes 支 持 的 优选 函数 

另外 ， 调 度 器 还 支持 为 每 个 优选 函数 指定 一 个 简单 的 由 正 数 值 表 示 
的 权重 ， 进 行 节点 优先 级 分 值 的 计算 时 ， 它 首先 将 每 个 优选 函数 的 计算 
得 分 乘 以 其 权重 (大 多 数 优先 级 的 默认 权重 为 1) ， 然 后 将 所 有 优选 函 
数 的 得 分 相 加 从 而 得 出 节点 的 最 终 优 先 级 分 值 。 权 重 属性 赋予 了 管理 员 





定义 优选 函数 倾 回 性 的 能 力 。 下 面 是 每 个 节点 的 最 终 优先 级 得 分 的 计算 


公式 : 


finalScoreNode= (weightl*priorityFunc1) + 
(weight2*priorityFunc2) +... 


下 面 是 各 优选 函数 的 相关 说 明 。 


1) LeastRequestedPriority: 由 节点 空间 资源 与 节点 总 容量 的 比值 计 
算 而 来 ， 即 由 CPU 或 内 存 资 源 的 总 容量 减 去 节点 上 已 有 Pod 对 象 需求 的 
容量 上 总和， 再 减 去 当前 要 创建 的 Pod 对 象 的 需求 容量 得 到 的 结果 除 以 总 
容量 。CPU 和 内 存 具 有 相同 的 权重 ， 资 源 空闲 比例 越 高 的 节点 得 分 就 越 
高 ， 其 计算 公式 为 : (cpu ( (capacity-sum (requested) ) 
*10/capacity) +memory ( (capacity-sum (requested) ) 
*10/capacity) ) /2。 








2) BalancedResourceAllocation: 以 CPU 和 内 存 资 源 占 用 率 的 相近 程 
序 作为 评估 标准 ， 二 者 越 接近 的 节点 权重 越 高 。 该 优选 级 函数 不 能 单独 
使 用 ， 它 需要 与 LeastRequestedPriority 组 合 使 用 来 平衡 优化 节点 资源 的 
上 以 选择 那些 在 部 署 当 前 Pod 资 源 后 系统 资源 更 为 均衡 的 节 








3) NodePreferAvoidPodsPriority: 此 优选 级 函数 权限 默认 为 10000， 
它 将 根据 节点 是 否 设置 了 注解 信 
息 “scheduler.alpha.kubernetes.io/preferAvoidPods” 来 计算 其 优选 级 。 计 算 
方式 是 : 给 定 的 节点 无 此 注解 信息 时 ， 其 得 分 为 10 乘 以 权重 10000; 存 
在 此 注解 信息 时 ， 对 于 那些 由 ReplicationController 或 ReplicaSet 控 制 器 管 
控 的 Pod 对 象 的 得 分 为 0， 其 他 Pod 对 象 会 被 忽略 〈 得 最 高 分 ) 。 


4) NodeAffinityPriority: 基于 节点 杀 和 性 调度 偏好 进行 优先 级 评 
佑 ， 它 将 根据 Pod 资 源 中 的 nodeSelector 对 给 定 节 点 进行 匹配 度 检 查 ， 成 
功 匹 配 到 的 条 目 越 多 则 节点 得 分 越 高 。 不 过 ， 其 评估 过 程 使 用 首选 而 非 
强制 型 的 “PreferredDuringSchedulingIgnoredDuringExecution” 标 签 选 择 
妖 。 


5) TaintTolerationPriority: 基于 Pod 资 源 对 节点 的 污点 容忍 调度 侦 
好 进行 其 优先 级 的 评估 ， 它 将 Pod 对 和 象 的 tolerations 列 表 与 节 扣 的 污点 进 
行 匹配 度 检查 ， 成 功 匹 配 的 条 目 越 多 ， 则 节点 得 分 越 低 。 

















6) SelectorSpreadPriority: 首先 碍 找 与 当前 Pod 对 象 匹 配 的 Service、 
ReplicationController、ReplicaSet (RS) 和 StatefulSet， 而 后 查找 与 这 些 
选择 器 匹配 的 现存 Pod 对 象 及 其 所 在 的 节点 ， 则 运行 此 类 Pod 对 象 越 少 的 
节点 得 分 将 越 高 。 人 简单 来 说 ， 如 其 名 称 所 示 ， 此 优选 函数 会 尽量 将 同一 
标签 选择 器 匹配 到 的 Pod 资 源 分 散 到 不 同 的 节点 上 运行 。 


7) InterPodAffinityPriority: 人 退 历 Pod 对 象 的 杀 和 性 条 有 目 ， 并 将 那些 
能 够 匹配 到 给 定 节 点 的 条 目的 权重 相 加 ， 结 果 值 越 大 的 节点 得 分 越 高 。 


) MostRequestedPriority: 与 优选 函数 LeastRequestedPriority 的 评估 
太 扩 得 分 的 方法 相似 ， 不 同 的 是 ， 资 源 占用 比例 越 大 的 市 挟 ， 其 得 分 越 
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了 


9) NodeLabelPriority: 根据 节点 是 否 拥有 特定 的 标签 来 评估 其 得 
分 ， 而 无 论 其 值 为 何 。 需 要 其 存在 时 ， 拥 有 相应 标签 的 节点 将 获得 优先 
级 ， 人 否则 ， 不 具有 相应 标签 的 节点 将 获得 优先 级 。 


10) ImageLocalityPriority: 基于 给 定 节 点 上 拥有 的 运行 当前 Pod 对 
象 中 的 容器 所 依赖 到 的 镜像 文件 来 计算 市 点 得 分 ， 不 具有 Pod 依 赖 到 的 
任何 镜像 文件 的 节点 其 得 分 为 0， 而 拥有 相应 镜像 文件 的 各 节点 中 ， 所 
拥有 的 被 依赖 到 的 镜像 文件 其 体积 之 和 越 大 则 节点 得 分 越 高 。 


Kubernetes 的 默认 调度 器 以 预选 、 优 选 、 选 定 机 制 完 成 将 每 个 新 的 
Pod 资 源 绑 定 至 为 其 选 出 的 目标 节点 上 ， 不 过 ， 它 只 是 Pod 对 象 的 默认 调 
度 器 ， 使 用 中 ， 用 户 还 可 以 自 定 义 调度 器 插件 ， 并 在 定义 Pod 资 源 配 置 
清单 时 通过 spec.schedulerName 指 定 即 可 使 用 。 





12.2 ”节点 杀 和 调度 


市 点 半 和 性 是 调度 程序 用 来 确定 Pod 对 象 调度 位 置 的 一 组 规则 ， 这 
些 规 则 基于 节点 上 的 自 定义 标签 和 Pod 对 象 上 指定 的 标签 选择 器 进行 定 
义 。 节 点 共和 性 允许 Pod 对 象 定义 针对 一 组 可 以 调度 于 其 上 的 节操 的 杀 
和 性 或 反 杀 和 性 ， 不 过 ， 它 无 法 具体 到 某 个 特定 的 节点 。 例 如 ， 将 Pod 
调度 至 有 着 特殊 CPU 的 节点 或 一 个 可 用 区 域内 的 节点 之 上 。 


定义 节点 杀 和 性 规则 时 有 两 种 类 型 的 节点 杀 和 性 规则 : 硬 杀 和 性 
Crequired) 和 软 杀 和 性 (preferred) 。 硬 杀 和 性 实现 的 是 强制 性 规则 ， 
它 是 Pod 调 度 时 必须 要 满足 的 规则 ， 而 在 不 存在 满足 规则 的 节点 时 ，Pod 
对 象 会 被 置 为 Pending 状 态 。 而 软 杀 和 性 规则 实现 的 是 一 种 柔性 调度 限 
制 ， 它 倾向 于 将 Pod 对 象 运行 于 某 类 特定 的 节点 之 上 ， 而 调度 器 也 将 尽 
量 满足 此 需求 ， 但 在 无 法 满足 调度 需求 时 它 将 退 而 求 其 次 地 选择 一 个 不 
匹配 规则 的 节点 。 


定义 节点 杀 和 规则 的 关键 点 有 两 个 ， 一 是 为 节点 配置 合乎 需求 的 标 
签 ， 另 一 个 是 为 Pod 对 象 定义 合理 的 标签 选择 器 ， 从 而 能 够 基于 标签 选 
择 出 符合 期 望 的 目标 节点 。 不 过 ， 如 
preferredDuringSchedulingIgnoredDuringExecution 和 
requiredDuringSchedulingIgnoredDuringExecution 名 字 中 的 后 半 段 符 串 
IgnoredDuringExecution 隐 含 的 意义 所 指 ， 在 Pod 资 源 基 于 节点 杀 和 性 规 
则 调度 至 某 贡 点 之 后 ， 节 点 标签 发 生 了 改变 而 不 再 符合 此 节点 和 性 规 
则 时 ， 调 度 器 不 会 将 Pod 对 象 从 此 节点 上 移出 ， 因 为 ， 它 仅 对 新 建 的 Pod 
对 象 生效 。 节 点 杀 和 性 模型 如 图 12-5 所 示 。 
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zone IN ["foo". "bar"] 
ssd EXISTS 


zone IN ["foo"] 


图 12-5 ”节点 杀 和 性 


12.2.1 节点 便 亲 和 性 


为 Pod 对 象 使 用 nodeSelector 属 性 可 以 基于 节点 标签 匹配 的 方式 将 
ee 类 特定 的 节点 之 上 ， 这 一 点 在 第 4 章 中 阐 曾 有 介 
绍 ， 不 过 它 仅 能 基于 简单 的 等 值 关系 定义 标签 选择 峰 ， de 
文 持 使 用 matchExpressions 属 性 构建 更 为 复杂 的 标签 选择 机 制 。 例 如 ， 
下 面 的 配置 清 下 Crequired-nodeAffinity-pod.yaml) 中 定义 的 Pod 对 
象 ， 其 使 用 节点 硬 杀 和 规则 定义 可 将 当前 Pod 对 象 调度 至 拥有 zone 标签 
且 其 值 为 foo 的 节点 之 上 : 














apiVersion: v1 
kind: Pod 
metadata: 
name: with-required-nodeaffinity 
spec: 
affinity: 
nodeAffinity: 
requiredDuringSschedulingIgnoredDuringExecution: 
nodeSelectorTerms: 
- matchExpressions: 
- {key: zone, operator: In, values: ["foo"]} 
containers: 
- name: myapp 
image: ikubernetes/myapp:vi 





将 上 面 配置 清单 中 定义 的 资源 创建 于 集群 之 中 ， 由 其 状态 信息 可 知 
它 处 于 Pending 阶 段 ， 这 是 由 于 强制 型 的 节点 杀 和 限制 场景 中 不 存在 能 
够 满足 匹配 条 件 的 节点 所 致 : 








~]$ kubectl apply -f required-nodeAffinity-pod.yaml 

pod "with-required-nodeaffinity" created 

~]$ kubect1 get pods with-required-nodeaffinity 

NAME READY STATUS RESTARTS AGE 
with-required-nodeaffinity 0/1 Pending 0 53s 





“kubectl describe” 命 令 显 示 的 资源 详细 信息 Events 字 上 段 中 也 给 出 了 具 
体 的 原因 “0/4nodesare available: 4node (s) didn't match node selector”， 
命令 及 结果 如 下 所 示 : 





~]$ kubectl1 describe pods with-required-nodeaffinity 


Events: 
Type Reason a From Message 
Warning FailedSscheduling 6s (x6 over 21s) default-scheduler 0/4 nodes are 
available: 4 node(s) didn't match node selector. 








接 下 来 按 图 12-5 中 的 规划 为 各 节点 设置 节点 标签 ， 这 也 是 设置 节点 
杀 和 性 的 前 提 之 一 : 





~]$ kubectl1 label node node02.ilinux.io zone=foo 
node "node02.ilinux.io" labeled 
~]$ kubectl1 label node node02.ilinux.io zone=foo 
node "node02.ilinux.io" labeled 
~]$ kubectl1 label node node03.ilinux.io zone=bar 
node "node03.ilinux.io" labeled 
~]$ kubectl1 label node node01.ilinux.io ssd=true 
node "node01.ilinux.io" labeled 
~]$ kubect1 label node node03.ilinux.io ssd=true 
node "node03.ilinux.io" labeled 





设置 完成 后 ，Pod 对 象 with-required- hy 的 详细 信息 事件 中 
己 然 出 现成 功 调 度 至 node01.ilinux.io 贡 点 的 信息 ， 有 具体 如 下 上 押 示 : 





Events: 
Type Reason Age From Message 
Warning FailedSscheduling 1m (x15 over 4m) default-scheduler 0/4 nodes 
are available: 4 node(s) didn't match node selector. 
Normal Scheduled 14s default-scheduler Successfully 


assigned with-required-nodeaffinity to node01.ilinux.io 








在 定义 市 点 杀 和 性 时 ， 
requiredDuringSchedulingIgnoredDuringExecution 字 上段 的 值 是 一 个 对 象 列 
表 ， 用 于 定义 节点 人 硬 杀 和 性 ， 它 可 由 一 到 多 个 nodeSelectorTerm 定 义 的 
对 象 组 成 ， 彼 此 间 为 “逻辑 或 ”的 关系 ， 进 行 匹 配 度 检查 时 ， 在 多 个 
要 满足 其 中 之 一 即 可 。nodeSelectorTerm 用 于 定 

点 选择 器 条 目 ， 其 值 为 对 象 列表 ， 电 可 由 一 个 或 多 个 
a 象 定 义 的 匹配 规则 组 成 ， 多 个 规则 彼此 之 间 为 “ 迎 辑 
与 ”的 关系 ， 这 就 意味 着 某 节 点 的 标签 需要 完全 匹配 同一 个 
i 所 有 的 it E wheseionX 象 定 义 的 规则 才 算 成 功 通 
过 节点 选择 器 条 目的 检查 。 而 matchExmpressions 又 可 由 一 到 多 个 标签 选 
择 器 组 成 ， 多 个 标签 选择 器 彼此 间 为 “逻辑 与 ”的 关系 。 














下 面 的 资源 配置 清单 示例 (required-nodeAffinity-pod2.yaml) 中 定 
义 了 调度 拥有 两 个 标签 选择 器 的 节点 挑选 条 目 ， 两 个 标签 选择 器 彼此 之 
间 为 “逻辑 与 ”的 关系 ， 因 此 ， 满 足 其 条 件 的 节点 为 node01 和 node03， 如 
图 12-5 右 侧 的 Pod 对 象 的 指向 所 示 : 








apiVersion: v1 


kind: Pod 
metadata: 
name: with-required-nodeaffinity-2 
spec: 
affinity: 
nodeAffinity: 
requiredDuringSchedulingIgnoredDuringExecution: 
nodeSelectorTerms: 
- matchExpressions: 
- {key: zone, operator: In, values: ["foo", "bar"]} 
- {key: ssd, operator: Exists, values: []} 
containers: 


- name: myapp 
image: ikubernetes/myapp:vi1 





构建 标签 选择 器 表达 式 中 支持 使 用 操作 符 有 In、NotIn、Exists、 
DoesNotExist、Lt 和 Gt 等 ， 具 体 的 用 法 请 参考 第 4 间 中 关于 标签 选择 器 的 


介绍 。 





另外 ， 调 度 器 在 调度 Pod 资 源 时 ， 节 点 灯 和 性 
(MatchNodeSelector) 仅 是 其 节点 预选 策略 中 遵循 的 预选 机 制 之 一 ， 其 
他 配置 使 用 的 预选 策略 依然 正 篆 参与 节点 预选 过 程 。 例 如 将 上 面 资 源 配 
置 清单 示例 中 定义 的 Pod 对 象 容器 修改 为 如 下 内 容 并 进行 测试 : 





containers: 
- name: myapp 
image: ikubernetes/myapp:vi1 
resources: 
requests: 
cpu: 6 
memory: 206Gi 





在 预选 策略 PodFitsResources 根 据 节点 资源 可 用 性 进行 节点 预选 的 过 
程 中 ， 它 会 获取 给 定 节 点 的 可 分 配 资 源 量 《资源 问题 减 去 已 被 运行 于 其 
上 的 各 Pod 对 象 的 requests 属 性 之 和 ) ， 云 除 那 些 无 法 容纳 新 Pod 对 象 请 
求 的 资源 量 的 节点 。 本 书 试验 环境 中 使 用 的 四 个 节点 (其 中 一 个 为 
Master) 配置 相同 ， 均 为 8 核心 CPU 和 16GB 内 存 ， 它 们 都 无 法 满足 容器 
myapp 的 需求 ， 因 此 调度 失败 ，Pod 资 源 会 被 置 于 Pending 状 态 。 下 面 是 





将 资源 创建 于 集群 中 ， 而 后 通过 其 详细 信息 获取 到 的 事件 ， 它 表明 集群 
中 仅 有 两 个 市 点 符 合 节 点 选择 器 ， 但 4 个 节点 都 不 具有 充足 的 内 存 资 源 
从 而 导致 调度 失败 : 








Events: 


available: 2 node(s) didn't match node selector, 4Insufficient memory. 





由 上 述 操作 过 程 可 知 ， 节 点 人 硬 杀 和 性 实现 的 功能 与 节点 选择 器 
(nodeSelector) 相似 ， 但 杀 和 性 支持 使 用 匹配 表达 式 来 挑选 节点 ， 这 
一 点 提供 了 有 灵活 且 强 大 的 选择 机 制 ， 因 此 可 被 理解 为 新 一 代 的 节点 选择 
和 


12.2.2 ”节点 软 亲 和 性 


市 点 软 杀 和 性 为 节点 选择 机 制 提供 了 一 种 柔性 控制 迎 辑 ， 被 调度 的 
Pod 对 象 不 再 是 “必须 ”而 是 “应 该 ”放置 于 某 些 特定 市 点 之 上 ， 当 条 件 不 
满足 时 ， 它 也 能 够 接受 被 编排 于 其 他 不 符合 条 件 的 节点 之 上 。 男 外 ， 它 
还 为 每 种 倾 问 性 提供 了 weight 属 性 以 便 用 户 定 义 其 优先 级 ， 取 值 范 围 是 
1 一 100， 数 字 越 大 优先 级 越 高 。 下 面 一 个 Deployment 资 源 配置 清单 示例 
(Cdeploy-with-preferred-nodeAffinity.yaml) : 





apiVersion: appSs/Vv1I 
kind: Deployment 
metadata: 
name: myapp-deploy-with-node-affinity 
spec: 
replicas: 3 
selector: 
matchLabels: 
app: myapp 
template: 
metadata: 
name: myapp-pod 
labels: 
app: myapp 
spec: 
affinity: 
nodeAffinity: 
preferredDuringSschedulingIgnoredDuringExecution: 
- weight: 60 
preference: 
matchExpressions: 
- {key: zone, operator: In, values: ["foo"]} 
- weight: 30 
preference: 
matchExpressions: 
- {key: ssd, operator: Exists, values: []} 
containers: 
- name: myapp 
image: ikubernetes/myapp:vi 








示例 中 ，Pod 资 源 模 板 定 义 了 节点 软 杀 和 性 以 选择 运行 在 拥有 
Zone=foo 和 ssd 标 签 〈 无 论 其 值 为 何 ) 的 节点 之 上 ， 其 中 zone=foo 是 更 为 
重要 的 倾向 性 规则 ， 它 的 权重 为 60， 相 比较 来 说 ，ssd 标 签 就 没有 那么 
关键 ， 它 的 权重 为 30。 这 么 一 来 ， 如 果 集 群 中 拥有 足够 多 的 节点 ， 和 那么 
它 将 被 此 规则 分 为 四 类 : 同时 满足 拥有 zone=foo 和 ssd 标 签 、 仅 具有 
Zoo=foo 标 签 、 仅 具有 ssd 标 签 ， 以 及 不 具备 此 两 个 标签 ， 如 图 12-6 所 
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图 12-6 ”节点 软 杀 和 性 


以 本 书 所 用 的 测试 环境 为 例 ， 它 共有 三 个 节点 《图 12-6 虚 线 内 的 节 
点 ) ， 相 对 于 myapp-deploy-with-node-affinity 中 定义 的 节点 亲 和 性 规则 
来 说 ， 它 们 所 拥有 的 倾 回 性 权重 分 别 如 图 12-6 中 标识 的 信息 所 示 。 在 创 
建 需 要 3 个 Pod 对 象 的 副本 时 ， 它 们 会 不 会 被 创 建 于 同一 节点 node01 之 
上 ? 下 面 来 验证 其 运行 效果 : 











~]$ kubect1l create -f deploy-with-preferred-nodeAffinity.yaml 

deployment.apps "myapp-deploy-with-node-affinity" created 

~]$ kubectl1 get pods -1 app=myapp -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 
myapp-deploy-..-8qrv7 1/1 Running 0 12s 10.244.2.131 node02.ilinux.io 
myapp-deploy-..-j5d7j 1/1 Running 0 12s 10.244.1.20 node01.ilinux.io 
myapp-deploy-..-twdsr 1/1 Running 0 12s 10.244.3.149 node03.ilinux.io 





结果 显示 ， 三 个 Pod 对 象 被 分 散 运行 于 集群 中 的 三 个 节点 之 上 ， 而 
非 集中 运行 于 node01 节 点 。 之 所 以 如 此 ， 是 因为 使 用 了 节点 软 杀 和 性 的 
预选 方式 ， 所 有 节点 均 能 够 通过 调度 器 上 MatchNodeSelector 预 选 策略 的 
虽 选 ， 因 此 ， 可 用 节点 取决 于 其 他 预选 策略 的 筛选 结果 。 在 第 二 阶段 的 
优选 过 程 中 ， 除 了 NodeAffinityPriority 优 选 函 数 之 外 ， 还 有 其 他 几 个 优 
选 函 数 参 与 优先 级 评估 ， 尤 其 是 SelectorSpreadPriority， 它 会 将 同一 个 
ReplicaSet 控 制 器 管控 的 所 有 Pod 对 象 分 散 到 不 同 的 节点 上 运行 以 抵御 节 
点 故障 带 来 的 风险 。 不 过 ， 这 种 节点 杀 和 性 的 权重 依然 在 发 挥 作用 ， 如 








果 把 副本 数量 扩展 至 越过 市 点 数 很 多 (如 15 个 ，， 那 么 它们 将 被 调度 器 
以 接近 节点 亲 和 性 权重 比值 (90: 60: 30) 的 方式 分 置 于 相关 的 节点 之 
上 ， 访 者 可 自行 验证 其 效果 。 


12.3 ”Pod 资 源 亲 和 调度 


出 于 高 效 通 信 的 需求 ， 偶 尔 需要 把 一 些 Pod 对 象 组 织 在 相近 的 位 置 
(同一 节点 、 机 架 、 区 域 或 地 区 等 ) ， 如 某 业 务 的 前 端 Pod 和 后 端 Pod 
等 ， 此 时 可 以 将 这 些 Pod 对 象 间 的 关系 称 为 杀 和 性 。 人 偶尔， 出 于 安全 或 
分 布 式 等 原因 也 有 可 能 需要 将 一 些 Pod 对 象 在 其 运行 的 位 置 上 隔离 开 
来 ， 如 在 每 个 区 域 运行 一 个 应 用 代理 Pod 对 象 等 ， 此 时 可 把 这 些 Pod 对 象 
间 的 关系 称 为 反 杀 和 性 〈anti-affinity) 。 


当然 ， 也 可 以 通过 节点 杀 和 性 来 定义 Pod 对 象 间 的 杀 和 或 反 杀 和 特 
性 ， 但 用 户 必须 为 此 明确 指定 Pod 可 运行 的 节点 标签 ， 显 然 这 并 非 较 优 
的 选择 。 较 理想 的 实现 方式 是 ， 人 允许 调度 器 把 第 一 个 Pod 放 置 于 任何 位 
置 ， 而 后 与 其 有 杀 和 或 反 亲 和 关系 的 Pod 据 此 动态 完成 位 置 编排 ， 这 右 
是 Pod 杀 和 性 调度 和 反 杀 和 性 调度 的 功用 。Pod 的 杀 和 性 定义 也 存 
在 “ 硬 ”(required) 亲 和 性 和 “ 软 ”(preferred〉 亲 和 性 的 区 别 ， 它 们 表示 
的 约束 意义 同 节点 杀 和 性 相似 。 


Kubernetes 调 度 器 通过 内 建 的 MatchInterPodAffinity 预 选 策略 为 这 种 
调度 方式 完成 节点 预选 ， 并 基于 InterPodAffinityPriority 优 选 函 数 进行 各 
节点 的 优选 级 评估 。 




















12.3.1 位置 拓扑 


Pod 亲 和 性 调度 需要 各 相关 的 Pod 对 象 运行 于 “同一 位 置 "， 而 反 亲 和 
性 调度 则 要 求 它们 不 能 运行 于 “同一 位 置 "。 何 谓 同一 位 置 ? 事实 上 ， 它 
们 取决 于 市 后 的 位 置 拓扑 ， 拓 x 扑 的 方式 不 同 ， 对 于 如 图 12-7 中 所 示 的 
Pod-A 和 Pod-B 是 否 在 同一 位 置 的 判定 结果 也 可 能 有 所 不 同 。 


如 果 以 基于 各 节点 的 kubernetes.io/hostname 标 签 作为 评判 标准 ， 那 
么 很 显然 , “同一 位 置 ? 意 味 着 同一 个 节点 ， 不 同 节 点 即 不 同 的 位 置 ， 如 
图 12-8 所 示 。 
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图 12-7 Pod 资源 与 位 置 拓扑 









Kubernetes.1o/hostnanme=selveI4 | Kubernetes.i0/hostname=server! 





Kubernetes.1i0/hostname=server3 | Kubernetes.1io/hostname=server2 
图 12-8 ”基于 节点 的 位 置 拓扑 
而 如 果 是 基于 如 图 12-9 所 划分 的 故障 转移 域 来 进行 评判 ， 那 么 


server1 和 server4 属 于 同一 位 置 ， 而 server2 和 server3 属 于 另 一 个 意义 上 的 
同一 位 置 。 





failure-domain.beta.kubernetes.10/zone=foo 


failure-domain.beta.kubernetes.10/zone=bar 


图 12-9 ”基于 故障 转移 域 的 位 置 拓扑 


故此 ， 在 定义 Pod 对 象 的 杀 和 性 与 反 杀 和 性 时 ， 需 要 借助 于 标签 选 
择 嚣 来 选择 和 被 依 赖 的 Pod 对 象 ， 并 根据 选 出 的 Pod 对 象 所 在 节点 的 标签 来 
判定 “同一 位 置 ?的 具体 意义 。 








12.3.2 ”Pod 硬 亲 和 调 度 


Pod 强 制约 束 的 杀 和 性 调度 也 使 用 
requiredDuringSchedulingIgnoredDuringExecution 属 性 进行 定义 。Pod 亲 
和 性 用 于 摘 述 一 个 Pod 对 象 与 具有 某 特 征 的 现存 Pod 对 象 运行 位 置 的 依赖 
关系 ， 因 此 ， 测 试 使 用 Pod 亲 和 性 约束 ， 需 要 事先 存在 被 依赖 的 Pod 对 
象 ， 它 们 具有 特别 的 识别 标签 。 下 面 创建 一 个 有 着 标签 “app=tomcat” 的 
Deployment 资 源 部 署 一 个 Pod 对 象 : 




















~]$kubect1 run tomcat- app=tomcat--image tomcat: alpine 





下 面 的 资源 配置 清单 〈required-podAffinity-podl.yaml) 中 定义 了 一 
个 Pod 对 象 ， 它 通过 labelSelector 定 义 的 标签 选择 器 挑选 感 兴 趣 的 现存 
Pod 对 象 ， 而 后 根据 挑选 出 的 Pod 对 象 所 在 节点 的 标 
签 “kubernetes.io/hostname” 来 判断 同一 位 置 的 具体 含义 ， 并 将 当前 Pod 对 
象 调度 至 这 一 位 置 的 某 节点 之 上 : 





apiVersion: v1 
kind: Pod 
metadata: 
name: with-pod-affinity-1 
spec: 
affinity: 
podAffinity: 
requiredDuringSschedulingIgnoredDuringExecution: 
- labelSelector: 
matchExpressions: 
- {key: app, operator: In, values: ["tomcat"]} 
topologyKey: kubernetes.io/hostname 
containers: 
- name: myapp 
image: ikubernetes/myapp:vi1 





事实 上 ，kubernetes.io/hostname 标 签 是 Kubernetes 集 群 节 点 的 内 建 标 
签 ， 它 的 值 为 当前 节点 的 节点 主机 名 称 标识 ， 对 于 各 个 节点 来 说 ， | 
不 同 。 因 此 ， 新 建 的 Pod 对 象 将 被 部 署 至 被 依赖 的 Pod 对 象 的 同一 节点 之 
上 ，requiredDuringSchedulingIgnoredDuringExecution 表 示 这 种 杀 和 性 为 
强制 约束 。 














~]$ kubect1 apply -f required-podAffinity-pod1.yaml 

~]$ kubectl get pods -o wide 

NAME READY _ STATUS RESTARTS AGE IP NODE 
tomcat-69f99cdf9d-6hvb5 1/1 Running 0 6m 10.244.3.152 node03.ilinux.j 
with-pod-affinity-1 1/1 Running 0 4s 10.244.3.154 nodeQ3.1ilinux.ji 





基于 单一 节点 的 Pod 杀 和 性 只 在 极 个 别 的 情况 下 才 有 可 能 会 用 到 ， 
较为 党 用 的 通常 是 基于 同一 地 区 (region) 、 区 域 (zone) 或 机 架 
(rack) 的 拓扑 位 置 约束 。 例如 部 署 应 用 程序 服务 (myapp) 与 数据 库 
Cdb) 服务 相关 的 Pod 时 ，db Pod 可 能 会 部 署 于 如 图 12-10 所 示 的 foo 或 
bar 这 两 个 区 域 中 的 某 节 点 之 上 ， 依 赖 于 数据 服务 的 myapp Pod 对 象 可 部 
署 于 db Pod 所 在 区 域内 的 节点 上 。 当 然 ， 如 果 db Pod 在 两 个 区 域 foo 和 
运行 ， 那 么 myapp Pod 将 可 以 运行 于 这 两 个 区 域 的 任何 节 
凡 之 


例如 ， 创 建 具有 两 个 拥有 标签 为 “app=db” 的 副本 Pod 作 为 被 依赖 的 
资源 ， 它 们 可 能 运行 于 类 似 图 12-5 所 示 的 三 个 节点 中 的 任何 一 个 或 两 个 
节点 之 上 ， 本 示例 中 它们 凑巧 运行 于 两 个 zone 标 签 值 不 同 的 节点 之 上 : 














~]$ kubectl run db -1] app=db --image=redis:alpine --replicas=2 

~]$ kubect1 get pods -1 app=db -o wide -w 

NAME READY STATUS RESTARTS AGE IP NODE 
db-6b97b54df7-gbs16 1/1 Running CL... node03.ilinux.io 
db-6b97b54df7-rhzrp 1/1 Running CL... node02.ilinux.io 
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podAffinity (required) 
labelSelector: 
app: db 
topologyKey: zone 


图 12-10 ”Pod 人 硬 灯 和 性 调度 


于 是 ， 依 赖 于 杀 和 于 这 两 个 Pod 的 其 他 Pod 对 象 可 运行 于 zone 标签 值 
为 foo 和 bar 的 区 域内 的 所 有 节点 之 上 。 下 面 的 资源 配置 清单 (deploy- 
with-required-podAffinity.yaml〉 中 正 是 定义 了 这 样 一 些 Pod 资 源 ， 它 们 
由 Deployment 控 制 器 所 创建 : 











apiVersion: apps/v1 
kind: Deployment 
metadata: 
name: myapp-with-pod-affinity 
spec: 
replicas: 3 
selector: 
matchLabels: 
app: myapp 
template: 
metadata: 
name: myapp 
labels: 
app: myapp 
spec: 


affinity: 
podAffinity: 
requiredDuringSchedulingIgnoredDuringExecution: 
- labelSelector: 
matchExpressions: 
- {key: app, operator: In, values: ["db"]} 
topologyKey: zone 
containers: 
- name: myapp 
image: ikubernetes/myapp:vi 





在 调度 示例 中 的 Deployment 控 制 占 创建 的 Pod 资 源 时 ， 调 度 器 首先 
会 基于 标签 选择 器 查询 拥有 标签 “app=db” 的 所 有 Pod 资 源 ， 接 着 获取 到 
它们 分 别 所属 的 节点 的 zone 标 签 值 ， 接 下 来 再 查询 拥有 逻 配 这 些 标签 值 
的 所 有 节点 ， 从 而 完成 节点 预选 。 而 后 根据 优选 函数 计算 这 些 节 点 的 优 
先 级 ， 从 而 挑选 出 运行 新 建 Pod 对 象 的 节点 。 


需要 注意 的 是 ， 如 果 节 点 上 的 标签 在 运行 时 发 生 了 更 改 ， 以 致 它 不 
再 满足 Pod 上 的 亲 和 性 规则 ， 但 该 Pod 还 将 继续 在 该 节点 上 运行 ， 因 此 它 
仅 会 影响 新 建 的 Pod 资 源 ， 另 外 ，labelSelector 属 性 仅 匹 配 与 被 调度 器 的 
Pod 在 同一 名 称 空间 中 的 Pod 资 源 ， 不 过 也 可 以 通过 为 其 添加 namespace 
字段 以 指定 其 他 名 称 空 间 。 











12.3.3 ”Pod 软 亲 和 调 度 


类 似 于 厄 点 杀 和 性 机 制 ，Pod 也 支持 使 用 
preferredDuringSchedulingIgnoredDuringExecution 属 义 柔 性 杀 和 机 
制 ， 调 度 器 会 尽力 确保 满足 杀 和 约束 的 调度 逻辑 ， 然 而 在 约束 条 件 不 能 
得 到 满足 时 ， 它 也 允许 将 Pod 对 象 调度 至 其 他 节点 运行 。 下 面 是 一 个 使 
用 了 Pod 软 杀 和 性 调度 机 制 的 资源 配置 清单 示例 〈deploy-with-preferred- 
podAffinity.yaml) : 














apiVersion: appSs/Vv1I 
kind: Deployment 
metadata: 
name: myapp-with-preferred-pod-affinity 
spec: 
replicas: 3 
selector: 
matchLabels: 
app: myapp 
template: 
metadata: 
name: myapp 
labels: 
app: myapp 
spec: 
affinity: 
podAffinity: 
preferredDuringSschedulingIgnoredDuringExecution: 
- weight: 80 
podAffinityTerm: 
labelSelector: 
matchExpressions: 
- {key: app, operator: In, values: ["cache"]} 
topologyKey: zone 
- weight: 20 
podAffinityTerm: 
labelSelector: 
matchExpressions: 
- {key: app, operator: In, values: ["db"]} 
topologyKey: zone 
containers: 
- name: myapp 
image: ikubernetes/myapp:vi 





它 定 义 了 两 组 杀 和 性 判定 机 制 ， 一 个 是 选择 cache Pod 所 在 节点 的 
zone 标 签 ， 并 赋予 了 较 高 的 权重 80， 男 一 个 是 选择 db Pod 所 在 节点 的 
zone 标 签 ， 它 有 着 略 低 的 权重 20。 于 是 ， 调 度 器 会 将 上 日 标 节点 分 为 四 
类 : cache Pod 和 db Pod 同 时 所 属 的 zone、cache Pod 单 独 所 属 的 zone、db 


Pod 单 独 所 属 的 zone， 以 及 其 他 所 有 的 zone。 


12.3.4 Pod 反 亲 和 调 度 


podAffinity 用 于 定义 Pod 对 象 的 杀 和 约束 ， 对 应 地 ， 将 其 蔡 换 为 
podAntiAffinty 即 可 用 于 定义 Pod 对 象 的 反 亲 和 约束 。 不 过 ， 反 亲 和 性 调 
度 一 般 用 于 分 散 同 一 类 应 用 的 Pod 对 象 等 ， 也 包括 将 不 同安 全 级 别 的 Pod 
对 象 调度 全 人 不同 的 区 域 、 机 染 或 节操 等 。 下 面 的 资 务 源 配置 清单 〈deploy- 
with-required-podAntiAffinity.yaml) 中 定义 了 由 同一 Deployment 创 建 但 
彼此 基于 节点 位 置 互 斥 的 Pod 对 象 : 





apiVersion: appSs/Vv1I 
kind: Deployment 
metadata: 
name: myapp-with-pod-anti-affinity 
spec: 
replicas: 4 
selector: 
matchLabels: 
app: myapp 
template: 
metadata: 
name: myapp 
labels: 
app: myapp 
spec: 
affinity: 
podAffinity: 
requiredDuringSschedulingIgnoredDuringExecution: 
- labelSelector: 
matchExpressions: 
- {key: app, operator: In, values: ["myapp"]} 
topologyKey: kubernetes.io/hostname 
containers: 
- name: myapp 
image: ikubernetes/myapp:vi 





由 于 定义 的 强制 性 反 杀 和 约束 ， 因 此 ， 创 建 的 4 个 Pod 副 本 必须 运行 
于 不 同 的 节点 中 。 不 过 ， 本 集群 中 一 共 只 存在 3 个 节点 ， 因 此 ， 必 然 地 
会 有 一 个 Pod 对 象 处 于 Pending 状 态 ， 如 下 所 示 : 





a kubectl1 get pods -o wide -1 app=myapp 


NAM READY STATUS RESTARTS AGE IP NODE 

a -4gcvv 0/1 Pending 0 2S <none> <none> 
myapp-..-788k6 1/1 Running oO node01.ilinux.io 
myapp-...-cxqv5 1/1 Running 0. node03.ilinux.io 
myapp-...-mk28s 1/1 Running 0 node02.ilinux.io 





类 似 地 ，Pod 反 杀 和 性 调度 也 文 持 使 用 柔性 约束 机 制 ， 在 调度 时 ， 
它 将 尽量 满足 不 把 位 置 相 斥 的 Pod 对 象 调 度 于 同一 位 置 ， 但 是 ， 当 约束 
关系 无 法 得 到 满足 时 ， 也 可 以 违反 约束 而 调度 。 读 者 可 参考 podAffinity 
的 柔性 约束 示例 将 上 面 的 Deployment 资 源 myapp-with-pod-anti-affinity 修 
改 为 柔性 约束 并 进行 调度 测试 。 


12.4 污点 和 容忍 度 


污点 〈taints) 是 定义 在 节点 之 上 的 键 值 型 属性 数据 ， 用 于 让 节点 拒 
绝 将 Pod 调 度 运行 于 其 上 ， 除 非 该 Pod 对 象 具 有 接纳 节点 污点 的 容忍 度 。 
而 容忍 度 (tolerations) 是 定义 在 Pod 对 象 上 的 键 值 型 属性 数据 ， 用 于 配 
置 其 可 容忍 的 节点 污点 ， 而 且 调 度 器 仪 能 将 Pod 对 象 调度 至 其 能 够 容 礼 
该 节点 污点 的 节点 之 上 ， 如 图 12-11 所 示 。 
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图 12-11 污点 与 容忍 之 间 的 关系 示意 图 


前 文中 ， 节 点 选择 器 (nodeSelector) 和 节点 亲 和 性 
CnodeAffinity) 两 种 调度 方式 都 是 通过 在 Pod 对 象 上 添加 标签 选择 器 来 
完成 对 特定 类 型 节点 标签 的 匹配 ， 它 们 实现 的 是 由 Pod 选 择 节 点 的 机 
制 。 而 污点 和 容 妨 度 则 是 通过 同 节 点 添加 污点 信息 来 控制 pod 对象 的 调 
度 结 果 ， 从 而 赋予 了 节点 控制 何 种 Pod 对 象 能 够 调度 于 其 上 的 主 控 权 。 
简单 来 说 ， 节 点 杀 和 性 使 得 Pod 对 象 被 吸引 到 一 类 特定 的 节点 ， 而 污点 
则 相反 ， 它 提供 了 让 节点 排斥 特定 Pod 对 象 的 能 


Kubernetes 使 用 PodToleratesNodeTaints 预 选 策略 和 
TaintTolerationPriority 优 选 函 数 来 完成 此 种 类 型 的 高 级 调度 机 制 。 











12.4.1 定义 污点 和 容忍 度 








污点 定义 在 节点 的 nodeSpec 中 ， 而 容忍 度 则 定义 在 Pod 的 podSpec 
中 ， 它 们 都 是 键 值 型 数据 ， 但 又 都 额外 支持 一 个 效果 (effect) 标记 ， 
语法 格式 为 “key=value: effect*， 其 中 key 和 value 的 用 法 及 格式 与 资源 注 
解 信息 相似 ， 而 effect 则 用 于 定义 对 Pod 对 象 的 排斥 等 级 ， 它 主要 包含 以 
下 三 种 类 型 。 


‘NoSchedule: 不 能 容 寂 此 污点 的 新 Pod 对 象 不 可 调度 至 当前 市 反 ， 
属于 强制 型 约束 关系 ， 节 点 上 现存 的 Pod 对 象 不 受 影 啊 。 


:PreferNoSchedule: NoSchedule 的 柔性 约束 版 本 ， 即 不 能 容 娟 此 污 
扩 的 新 Pod 对 象 尽量 不 要 调度 全 当前 节 反 ， 不 过 无 其 他 市 点 可 供 调度 时 
也 允许 接受 相应 的 Pod 对 象 。 节 点 上 现存 的 Pod 对 象 不 受 影响 。 


:NoExecute: 不 能 容忍 此 污点 的 新 Pod 对 象 不 可 调度 至 当前 节点 ， 
属于 强制 型 约束 关系 ， 而 且 市 点 上 现存 的 Pod 对 象 因 节点 污点 变动 或 Pod 
容忍 度 变 动 而 不 再 满足 匹配 规则 时 ，Pod 对 象 将 被 驱逐 。 


此 外 ， 在 Pod 对 象 上 定义 容忍 度 时 ， 它 文 持 两 种 操作 符 ， 一 种 是 等 
值 比较 〈Equal) ， 表 示 容 忍 度 与 污点 必须 在 key、value 和 effect 三 者 之 
上 完全 匹配 ; 另 一 种 是 存在 性 判断 〈Exists) ， 表 示 二 者 的 key 和 effect 必 
须 完 全 匹配 ， 而 容忍 度 中 的 value 字 段 要 使 用 空 值 。 


另外 ， 一 个 节点 可 以 配置 使 用 多 个 污点 ， 一 个 Pod 对 象 也 可 以 有 多 
个 容忍 度 ， 不 过 二 者 在 进行 匹配 检查 时 应 章 循 如 下 逻辑 。 


1) 首先 处 理 每 个 有 痢 与 之 匹配 的 容忍 度 的 污点 。 


2) 不 能 匹配 到 的 污点 上 ， 如 果 存 在 一 个 污点 使 用 了 NoSchedule 效 
用 标识 ， 则 拒绝 调度 Pod 对 象 至 此 节点 。 


3) 不 能 匹配 到 的 污点 上 ， 若 没有 任何 一 个 使 用 了 NoSchedule 效 用 
标识 ， 但 至 少 有 一 个 使 用 了 PreferNoScheduler， 则 应 尽量 避免 将 Pod 对 
象 调度 至 此 节点 。 

















4) 如 果 至 少 有 一 个 不 匹配 的 污点 使 用 了 NoExecute 效 用 标识 ， 则 节 
点 将 立即 驱逐 Pod 对 象 ， 或 者 不 予 调度 至 给 定 节 点 ; 另外 ， 即 便 容 忍 度 
可 以 匹配 到 使 用 了 NoExecute 效 用 标识 的 污点 ， 知 在 定义 容忍 度 时 还 同 
时 使 用 tolerationSeconds 属 性 定义 了 容忍 时 限 ， 则 超出 时 限 后 其 也 将 被 节 
点 驱逐 


使 用 kubeadm 部 署 的 Kubernetes 和 集群 ， 其 Master 节 点 将 自动 添加 污点 
埋 恩 以 阻止 不 能 容忍 此 污点 的 Pod 对 象 调 度 至 此 节点 ， 因 此 ， 用 户 手 动 
创建 的 未 特意 添加 容忍 此 污点 容忍 度 的 Pod 对 象 将 不 会 被 调度 至 此 节 


. 
de 











~]$ kubectl1 describe node master.ilinux.io 


Name: master .ilinux.io 
Roles: master 
Labels: beta.kubernetes.io/arch=amd64 


beta.kubernetes.io/o0os=1linux 
kubernetes.io/hostname=master .ilinux.io 
node-role.kubernetes.io/master= 
Taints: node-role.kubernetes.io/master:NoSschedule 
Unschedulable: false 





不 过 ， 有 些 系 统 级 应 用 ， 如 kube-proxy 或 者 kube-flannel 等 ， 都 在 资 
源 创建 时 就 添加 上 了 相应 的 容忍 度 以 确保 它们 被 DaemonSet 控 制 器 创建 
时 能 够 调度 至 Master 节 点 运行 一 个 实例 : 





~]$ kubect1 describe pods kube-flannel-ds-lsgqr -n kube-system 

Node-Selectors: beta.kubernetes.io/arch=amd64 

Tolerations : node-role.kubernetes.io/master:NoSschedule 
node.kubernetes.io/disk-pressure:Noschedule 
node.kubernetes.io/memory-pressure:NoSchedule 
node.kubernetes.io/not-ready:NoExecute 
node.kubernetes.io/unreachable:NoExecute 








另外 ， 这 类 Pod 是 构成 Kubernetes 系 统 的 基础 且 关 键 性 的 组 件 ， 它 们 
甚至 还 定义 了 更 大 的 容忍 度 。 从 上 面 某 kube-flannel 实 例 的 容忍 度 定 义 来 
它 还 能 容忍 那些 报告 了 人 磁 税 压力 或 内 存 压 力 的 节点 ， 以 及 未 束 绪 的 
点 和 不 可 达 的 节点 ， 以 确保 它们 能 在 任何 状态 下 正常 调度 至 集群 节点 

二 位: 





12.4.2 ”管理 节点 的 污点 


任何 符合 其 键 值 规范 要 求 的 字符 串 均 可 用 于 定义 污点 信息 : 仅 可 使 
用 字母 、 数 字 、 连 接 符 、 点 号 和 下 划 线 ， 且 仪 能 以 字母 或 数字 开头 ， 其 
中 键 名 的 长 度 上 限 为 253 个 字符 ， 值 最 长 为 63 个 字符 。 实 践 中 ， 污 点 通 
常用 于 描述 具体 的 部 署 规划 ， 它 们 的 键 名 形 如 node-type、node-role、 
node-project 或 node-geo 等 ， 因 此 还 可 在 必要 时 带 上 域名 以 描述 其 额外 的 
信息 ， 如 node-type.ilinux.io 等 。 使 用 “kubectl taint”* 命 令 即 可 同 节 点 添加 
污点 ， 命 令 的 语法 格式 如 下 : 





kubect] taint nodes <node-name> <key>=<value>:<effect> .… 





例如 ， 使 用 “node-type=production: NoSchedule” 定 义 节点 
node01.ilinux.io: 





~]$ kubectl1 taint nodes node01.ilinux.io node-type=production:NoSchedule 
node "node01.ilinux.io" tainted 





此 时 ，node01 上 已 有 的 Pod 对 象 不 受 影响 ,但 新 建 的 Pod 大 不 能 容 芒 
ed 类 似 下 面 的 命令 可 以 查看 节点 上 的 污 


. 
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~]$ kubect1 get nodes node01.ilinux.io -0 go-template={{.spec.taints}} 
[map[value:production effect:NoSschedule key:node-type]] 








需要 注意 的 是 ， 即 便 是 同一 个 键 值 数据 ， 若 其 效用 标识 不 同 ， 则 其 
也 分 属于 不 同 的 污点 信息 ， 例 如 ， 将 上 面 命令 中 的 效用 标识 定义 为 
PreferNoSchedule 再 添加 一 次 : 








~]$ kubect1l taint nodes node01.ilinux.io node-type=production:PreferNoSchedujle 
node "node01.1i1inux.Io" tainted 





删除 某 污点 ， 仍 然 通过 kubectl taint 命 令 进 行 ， 但 要 使 用 如 下 的 命令 


格式 ， 和 省略 效用 标识 则 表示 删除 使 用 指定 键 名 的 所 有 污点 ， 否 则 区 只 删 
除 指定 键 名 上 对 应 效用 标识 的 污点 : 








kubect] taint nodes <node-name> <key>[:<effect>]- 





例如 ， 删 除 node01 上 node-type 键 的 效用 标识 为 “NoSchedule” 的 污点 
信 自 


vv ; 





~]$ kubectl1 taint nodes node01.ilinux.io node-type:NoSschedule- 
node "node01.ilinux.io" untainted 





各 要 删除 使 用 指定 键 名 的 所 有 污点 ， 则 在 删除 命令 中 省 略 效用 标识 





~]$ kubectl1 taint nodes node01.ilinux.io node-type- 
node "node01.ilinux.io" untainted 





删除 节点 上 的 全 部 污点 信息 ， 通 过 kubectl patch 命 令 将 节点 属性 
spec.taints 的 值 直接 置 空 即 可 ， 例 如 : 





~]$ kubectl1 patch nodes node01.ilinux.io -p '{"spec":{"taints":[]}}' 
node "node01.ilinux.io" patched 








节点 污点 的 变动 会 影响 到 新 建 Pod 对 象 的 调度 结果 ， 而 且 使 用 
NoExecute 进 行 标识 时 ， 还 会 影响 到 节点 上 现 有 的 Pod 对 象 。 


12.4.3 ”Pod 对 象 的 容 妨 度 


Pod 对 象 的 容忍 度 可 通过 其 spec.tolerations 字 段 进 行 添加 ， 根 据 使 用 
的 操作 符 不 同 ， 主 要 有 两 种 可 用 的 形式 : 一 种 是 与 污点 信息 完全 匹配 的 
等 值 关系 ; 另 一 种 是 判断 污点 信息 存在 性 的 匹配 方式 。 使 用 Equal 操作 
符 的 示例 如 下 所 示 ， 其 中 tolerationSeconds 用 于 定义 延迟 驱逐 当前 Pod 对 
象 的 时 长 : 








tolerations: 

- key: "key1" 
operator: "Equal" 
value: "valuel1" 
effect: "NoExecute" 
tolerationSeconds: 3600 





使 用 存在 性 判断 机 制 的 容 妨 度 示例 如 下 所 示 : 





tolerations: 

- key: "key1" 
operator: "Exists" 
effect: "NoExecute" 
tolerationSeconds: 3600 








实践 中 ， 若 集群 中 的 一 组 机 器 专用 于 为 运行 非 生 产 型 的 容器 应 用 而 
备 置 ， 而 且 它 们 可 能 随时 按 需 上 下 线 ， 那 么 就 应 该 为 其 添加 污点 信息 ， 
以 确保 仅 那 些 能 容忍 此 污点 的 非 生产 型 Pod 对 象 可 以 调度 其 上 。 男 外 ， 
某 些 有 着 特殊 人 硬件 的 节点 需要 专用 于 运行 一 类 有 着 此 类 硬件 资源 需求 的 
Pod 对 象 时 ， 例 如 ， 那 些 有 着 SSD 或 GPU 的 设备 ， 也 应 该 为 其 添加 污点 
信息 以 排除 其 他 的 Pod 对 象 。 





12.4.4 问题 节点 标识 








Kubernetes 自 1.6 版 本 起 支持 使 用 污点 上 自动 标识 问题 节点 ， 它 通过 节 
点 控制 器 在 特定 条 件 下 自动 为 节点 添加 污点 信息 实现 。 它 们 都 使 用 
NoExecute 效 用 标识 ， 因 此 不 能 容 礼 此 类 污点 的 现 有 Pod 对 象 也 会 遭 到 驱 
逐 。 目 前 ， 内 建 使 用 的 此 类 污点 包含 如 下 几 个 。 


:node.kubernetes.io/not-ready: 节点 进入 “NotReady” 状 态 时 被 自动 添 
加 的 污点 。 


.node.alpha.kubernetes.io/unreachable: 节点 进入 “NotReachable” 状 态 
时 被 自动 添加 的 污点 。 


:node.kubernetes.io/out-of-disk: 节点 进入 “OutOfDisk” 状 态 时 被 自动 
添加 的 污点 。 


.node.kubernetes.io/memory-pressure: 节点 内 存 资源 面临 压力 。 











node.kubernetes.io/disk-pressure: 节点 磁盘 资源 面临 压力 。 
:node.kubernetes.io/network-unavailable: 节点 网 络 不 可 用 。 


:node.cloudprovider.kubernetes.io/uninitialized: kubelet 由 外 部 的 云 环 
卉 程序 局 动 时 ， 它 将 目 劲 为 节 扩 添加 此 污点 ， 行 到 云 控制 器 管理 融 中 的 
控制 器 初始 化 此 节点 时 再 将 其 删除 。 


不 过 ，Kubernetes 的 核心 组 件 通常 都 要 容忍 此 类 的 污点 ， 以 确保 其 
相应 的 DaemonSet 控 制 句 能 够 无 视 此 类 污点 ， 于 节点 上 部 署 相应 的 关键 
性 Pod 对 象 ， 例 如 kube-proxy 或 kube-flannel 等 。 








12.5 “Pod 优 选 级 和 抢占 式 调度 


Kubernetes 上 自 1.8 版 本 起 开始 文 持 Pod 资 源 的 优选 级 机 制 ， 它 用 于 表 
现 一 个 Pod 对 象 相对 于 其 他 Pod 对 象 的 重要 程度 。 一 个 Pod 对 象 无 法 被 调 
度 时 ， 调 度 嚣 会 尝试 抢占 (驱逐 ) 较 低 优先 级 的 Pod 对 象 ， 以 便 可 以 调 
度 当 前 Pod。 另 外 ， 在 Kubernetes 1.9 和 更 高 版 本 中 ， 优 先 级 还 会 影响 节 
点 上 Pod 的 调度 顺序 和 驱逐 次 序 。 


不 过 ，Pod 优 选 级 和 抢占 机 制 默认 处 于 禁用 状态 ， 如 需 启用 ， 则 需 
要 同时 为 kube-apiserver、kube-scheduler 和 kubelet 程 序 的 “--feature- 
gates” 选 项 添加 “PodPriority=true” 和 条目。 添加 完成 后 ， 事 先 创建 好 优先 级 
类 别 ， 并 在 创建 Pod 资 源 时 通过 priorityClassName 属 性 指定 其 所 属 的 优选 
级 类 别 即 可 。 


此 种 特性 目前 仍 处 于 Alpha 阶 段 ， 因 此 ， 本 章 不 再 对 其 进行 过 多 的 
描述 ， 感 兴趣 的 读者 可 参考 文档 进行 测试 。 


12.6 本章 小 结 


本 章 讲 解 了 Kubernetes 默 认 调度 器 的 分 步调 度 机 制 ， 描 述 了 各 预选 
打上 略 和 优选 沙 数 的 功能 ， 并 对 节点 亲 和 性 调度 、Pod 亲 和 性 调度 以 及 基 
于 污点 和 容 妨 的 局 级 调度 方式 进行 了 重点 说 明 。 


第 13 半 Kubernetes 系 统 扩展 


Kubernetes 系 统 的 扩展 和 增强 既 包 括 扩展 API Server 所 支持 的 资源 类 
型 及 相关 声明 式 功 能 的 实现 ， 以 及 消除 集群 的 单 点 以 实现 集群 的 高 可 用 
等 ， 也 包括 如 何 将 系统 增强 为 一 个 完整 意义 上 的 PaaS 平 台 ， 并 以 
DevOps 文 化 为 驱动 改善 工作 流程 等 。 





13.1 自 定 义 资 源 类 型 (CRD ) 


Kubernetes API 默 认 提 供 的 众多 的 功能 性 资源 类 型 可 用 于 容器 编排 
以 解决 多 数 场景 中 的 编排 需求 。 然 而 ， 有 些 场景 也 许 要 借助 于 额外 的 或 
更 高 级 别 的 编排 抽象 ， 例 如 引入 集群 外 部 的 一 些 服 务 并 以 资源 对 象 的 形 
式 进 行 管 理 ， 再 或 者 把 Kubernetes 的 多 个 标准 资源 对 象 合并 为 一 个 单一 
的 更 高 级 别 的 资源 抽象 ， 等 等 。 而 这 类 API 扩 展 抽 象 通 常 也 应 该 兼容 
Kubernetes 系 统 的 基本 特性 ， 如 支持 kubectl 管 理工 具 、CRUD 及 watch 机 
制 、 标 签 、etcd 存 储 、 认 证 、 授 权 、RBAC 及 审计 ， 等 等 ， 从 而 使 得 用 
户 可 将 精力 集中 于 构建 业务 逻辑 本 身 。 


目前 ， 扩 展 Kubernetes API 的 常用 方式 有 三 种 : 使 用 
CRD (CustomResourceDefinitions) 自 定 义 资源 类 型 、 开 发 自 定 义 的 API 
Server 并 聚合 至 主 API Server， 以 及 定制 扩展 Kubernetes 源 码 。 其 中 ， 
CRD 最 为 易 用 但 限制 颇 多 ， 自 定义 API Server 更 富 于 弹性 但 代码 工作 量 
偏 大 ， 而 仪 在 必须 添加 新 的 核心 类 型 才能 确保 专用 的 Kubernetes 集 群 功 
能 正常 时 才 应 该 定制 系统 源码 。 


在 某 种 程度 上 ，Kubernetes API Server 可 以 看 作 一 个 JSON 方 案 的 数 
据 库 存储 系统 ， 它 内 建 了 众多 数据 模式 (资源 类 型 ) ， 以 etcd 为 存储 后 
端 ， 支 持 存 储 和 检索 结合 内 建 模式 进行 实例 化 的 数据 项 (对 象 ) 。 作 为 
客户 端 ， 控 制 喜 会 收 到 有 关 这 些 资源 对 象 变动 的 通知 ， 并 在 啊 应 过 程 中 
操纵 这 些 对 象 及 相关 的 其 他 资源 ， 或 者 将 这 些 更 改 反 映 到 外 部 系统 (如 
云端 的 软件 负载 平衡 器 ) 。 从 这 个 角度 进行 类 比 ，CRD 就 像 是 由 用 户 为 
Kubernetes 存 储 系 统 提供 的 自 定 义 数据 模式 ， 基 于 这 些 模 式 进 行 实 例 化 
的 数据 项 一 样 可 以 存 入 系统 中 。 


CRD 并 非 设计 用 来 取代 Kubernetes 的 原生 资源 类 型 ， 而 是 用 于 补充 
一 种 简单 易 用 的 更 为 灵活 和 更 高 级 别 的 上 自 定 义 API 资 源 的 方式 。 虽 然 目 
前 在 功能 上 仍 存 在 不 少 的 局 了 上限， 但 对 于 大 多 数 的 需求 场景 来 说 ，CRD 的 
表现 已 经 足够 好 ， 因此 在 满足 需求 的 前 提 下 是 首选 的 API 资 源 类 型 扩展 
方案 。 
































13.1.1 创建 CRD 对 象 


CRD 目 Kubernetes 1.7 版 开始 引入 ， 并 目 1.8 版 起 完全 取代 其 前 映 
TPR 〈ThirdParty-Resources) ， 其 设计 目标 是 无 顷 修改 Kubernetes 源 代码 
就 能 扩展 它 支 持 使 用 API 资 源 类 型 。CRD 本 身 也 是 一 种 资源 类 型 ， 隶 属 
于 集群 级 别 ， 实 例 化 出 特定 的 对 象 之 后 ， 它 会 在 API 上 注册 生成 GVR 类 
型 URL 端 点 ， 并 能 够 作为 一 种 资源 类 型 被 使 用 并 实例 化 相应 的 对 象 。 上 自 
定义 资源 类 型 之 前 ， 选 定 其 使 用 的 API 群 组 名 称 、 版 本 及 新 建 的 资源 类 
型 名 称 ， 根 据 这 些 信息 即 可 创建 自 定义 资源 类 型 ， 并 创建 自 定义 类 型 的 
资源 对 象 ， 其 流程 如 图 13-1 所 示 。 





kind:CustomResourcDefinition kind:CustomResourcType 







Custom Resourc 
(@]o] [A 


”CustomResourceType 


Object 
图 13-1 创建 自 定 义 资源 类 型 及 自 定义 类 型 的 资源 对 象 


下 面 的 配置 清单 中 定义 了 一 个 名 为 users.auth.ilinux.io 的 CRD 资 源 对 
象 ， 它 的 群 组 名 称 为 auth.ilinux.io， 仅 文 持 一 个 版 本 级 询 v1betal1， 复 数 
形式 为 users， 隶 属于 名 称 空间 级 别 ， 因 此 ， 它 的 对 象 在 API 上 的 URL 路 
径 前 级 为 /apis/auth.ilinux.io/vlbetal/namespace/NS_NAME/users/: 





apiVersion: apiextensions.k8s.io/vibetal 
kind: CustomResourceDefinition 
metadata: 
name: users.auth.ilinux.io 
spec: 
group: auth.ilinux.io 
version: vibetal1 
names: 
kind: User 
plural: users 
singular: user 
shortNames: 
- U 
scope: Namespaced 





配置 清单 中 ，spec 找 套 使 用 的 字段 都 能 够 见 名 知 义 ， 这 里 需要 特别 


说 明 的 是 ，metadata.name 字 段 的 值 必须 等 同 于 spec 字 段 中 

的 “<names.plural>.<group>” 合 并 起 来 的 形式 。 将 清单 中 的 CRD 资 源 创建 
于 Kubernetes 集 群 中 之 后 ， 继 而 创建 一 个 新 的 CustomResourceDefinition 
类 型 的 对 象 ， 例 如 ， 使 用 下 面 的 命令 列 出 集群 上 的 CRD 对 象 时 ， 命 令 结 
果 将 显示 出 如 下 资源 名 称 及 创建 时 间 状 态 信 息 : 





~]$ kubectl1 get crd 
NAME CREATED AT 
users.auth.ilinux.io 2018-08-24T12:51:54Z 





现在 ， 在 API 群 组 auth.ilinux.io/vlbetal 中 ，users 已 经 是 一 个 名 称 空 
间 级 别 的 可 用 资源 类 型 ， 用 户 可 按 需 创建 出 任意 数量 的 users 类 型 的 对 
象 ， 下 面 就 是 一 个 资源 清单 示例 ， 它 定义 了 一 个 名 为 admin 的 users 对 
象 : 





apiVersion: auth.ilinux.io/vibeta1 
kind: User 
metadata: 
name: admin 
namespace: default 
spec: 
userID: 1 
email: k8s@ilinux.io 
groups: 
- Superusers 
- adminstrators 
password: ikubernetes 





目 定 义 资源 类 型 users 并 未 限制 其 spec 字 段 中 可 通 套 使 用 的 字段 及 其 
数据 类 型 ， 于 是 用 户 可 按 需 随意 使 用 任何 字段 名 及 字段 值 ， 例 如 上 面 的 
资源 清单 中 使 用 的 userID 、email 和 groups 等 字段 。 资 源 创建 完成 后 即 可 
使 用 users 作 为 类 型 标识 使 用 kubectl 命 令 完 成 资源 对 象 的 管理 ， 包 括 查 
看 、 删 除 、 修 改 等 操作 。 例 如 ， 将 清单 中 的 自 定义 资源 创建 于 名 称 空间 
中 ， 而 后 使 用 类 似 如 下 的 命令 获取 相关 的 状态 信息 : 

















~]$ kubectl get users -n default 
NAME AGE 
admin 10s 





根据 API 对 象 GVR 格 式 的 URL 规 范 ，users 资 源 的 对 象 admin 的 引用 


路 径 为 /apis/auth.ilinux.io/vlbetal/namespaces/defaulVyusers/admin， 这 一 点 


可 以 通过 describe 命 令 予 以 证 实 。 而 要 删除 自 定义 的 users 对 象 admin， 只 
要 使 用 通用 格式 的 kubectl 命 令 即 可 ， 如 “kubectl delete users admin”， 或 
者 使 用 陈述 式 对 象 配 置 命 令 “kubectl delete-f<filename>”。 


13.1.2 上 自 定义 资源 格式 验证 


除了 对 操作 请 求 进行 身份 认证 和 授权 检查 之 外 ， 对 象 配置 的 变动 在 
存 入 etcd 之 前 还 需要 经 由 准 入 控制 费 的 核验 ， 尤 其 是 验证 型 
Cvalidation) 控制 器 会 检查 传 入 的 对 象 格 式 是 否 符 合 有 效 格式 ， 包 括 是 
企 设 定 了 个 得 合 定义 的 数据 交 腻 什 ， 以 及 是 否 违反 了 字段 的 限制 规则 





Kubernetes 目 1.9 版 本 起 文 持 为 CRD 和 定义 验 证 〈validation 字 段 ) 机 制 
用 以 定义 CRD 可 用 的 有 效 字 段 等 ， 这 在 将 设计 的 上 自 定 义 资 源 公 开 应 用 时 
非常 重要 。 自 定义 资源 可 使 用 OpenAPI 模 式 声明 验证 规则 ， 该 模式 是 
JSON 模 式 的 子 集 。 需 要 注意 的 是 ，OpenAPI 架 构 并 不 能 支持 JSON 架 构 
的 所 有 功能 ， 而 CRD 验 证 也 不 能 文 持 OpenAPI 架 构 的 所 有 功能 ， 不 过 ， 
对 于 大 多 数 情况 来 说 ， 它 足够 用 了 。 





@ CRD 的 validation 中 支持 使 用 的 限制 机 制 、 数 据 类 型 及 
数据 格式 等 请 参考 其 API 手 册 。 


下 面 是 一 个 配置 清单 片段 ， 将 其 合并 添加 到 13.1.1 节 中 CRD 对 象 
users.auth.ilinux.io 配 置 清单 的 spec 内 即 能 生效 。 它 分 别 定义 了 userID、 
groups、email 和 password 字 段 的 数据 类 型 ， 并 指定 了 userID 字 段 的 取 值 
范围 ， 以 及 password 字 段 的 数据 格式 ， 而 且 还 通过 required 指 定 userID 和 
groups 是 必 选 字段 : 





spec: 
validation: 
openAPIV3Schema: 
properties: 
spec: 
properties: 
userID: 
type: integer 
minimum: 1 
maximum: 65535 
groups: 
type: array 
email: 
type: string 
password: 
type: string 
format: password 


required: ["userID","groups"] 





限制 了 每 个 字段 的 数据 类 型 之 后 ， 验 证 机 制 会 检查 创建 或 修改 操作 
中 提供 的 每 个 字段 值 等 是 否 违反 了 格式 要 求 ， 任 何 的 核验 失败 都 会 导致 
写 入 操作 被 拒绝 。 下 面 的 内 容 是 某 次 创建 操作 返回 的 错误 提示 ， 它 显示 
命令 提供 的 对 象 配置 信息 违反 了 userID 字 段 的 取 值 范围 ， 并 且 缺 少 必 选 
字段 : spec.groups。 





The User "tony" is invalid: []: .… 

.: Validation failure list: 

spec.userID in body should be less than or equal to 65535 
spec.groups in body is required 





自 Kubernetes 1.11 版 本 开始 ，kubectl 即 使 用 服务 器 侧 对 象 信息 打印 
机 制 ， 这 意味 着 将 由 API Server 决 定 kubectl get 命 令 结果 会 显示 哪些 字 
段 。 在 CRD 资 源 中 ， 可 在 spec.additionalPrinterColumns 中 构 套 定义 在 对 
象 的 详细 信息 中 要 打印 的 字段 列表 。 下 面 的 配置 清单 片断 定义 了 要 为 
users 类 型 的 对 象 显示 相关 的 四 个 字段 ， 将 其 合并 至 前 面 定义 的 CRD 对 象 
users 配 置 清单 的 spec 字 段 中 ， 重 新 应 用 到 集群 中 并 确保 其 正常 生效 : 











spec: 
additionalPrinterColumns: 
- name: userID 
type: integer 
description: The user ID. 
JSONPath: .spec.userID 
- name: groups 
type: string 
description: The groups of the user. 
JSONPath: .spec.groups 
- name: email 
type: string 
description: The email address of the user. 
JSONPath: .spec.email 
- name: password 
type: string 
description: The password of the user account. 
JSONPath: .spec.password 





以 上 站 个 字段 会 显示 在 get、describe 等 命令 查看 users 类 型 的 对 象 状 
态 信息 的 输出 结果 中 : 





~]$ kubect1 get users admin 


NAME USERID GROUPS EMAIL PASSWORD 
admin 1 [superusers administrators] k8s@ilinux.io ikubernetes 








当然 ， 在 对 象 中 以 明文 字符 串 保 存 密码 并 不 是 一 个 好 的 选择 ， 真 正 
到 时 ， 应 该 使 用 Secret 对 象 保 存 密 钥 信 息 ， 并 在 users 对 象 中 进行 引 


13.1.3” 子 资 源 


可 能 有 读者 已 经 注意 到 ， 前 面目 定义 资源 users 的 对 象 admin 在 其 详 
细 状 态 信 息 输 出 中 没有 类 似 核心 资源 的 status 字 段 ， 该 字段 是 一 种 用 于 
保存 对 象 当前 状态 的 子 资源 。 在 Kubernetes 系 统 的 声明 式 API 中 ，status 
字段 至 关 重 要 ， 它 由 Kubernetes 系 统 目 行 维护 ， 相 关 的 控制 器 在 和 解 循 
环 中 持续 与 API Server 进 行 通信 ， 并 负责 确保 status 字 段 中 的 状态 匹配 
spec 字 段 中 定义 的 期 望 状态 。 


在 Kubernetes 1.10 版 本 之 前 ， 自 定义 资源 的 API 端 点 不 区 分 spec 和 
status 字 段 ， 而 自 1.10 版 本 起 ， 目 定义 资源 开始 文 持 通过 /status 子 资源 的 
方式 提供 对 象 的 当前 状态 ， 虽 然 它 仍然 不 会 显示 于 获取 状态 信息 的 命令 
结果 输出 中 ， 但 客户 端 可 通过 对 象 的 子 URL 路 径 来 获取 状态 信息 。 此 特 
性 在 1.11 版 本 中 已 经 升级 至 beta 级 别 。 


在 CRD 中 为 自 定 义 资源 启用 status 字 段 的 方式 非常 简单 ， 只 需要 为 


其 定义 spec.subresources.status 字 段 即 可 ， 其 内 骸 的 字段 等 由 系统 自行 维 
护 ， 用 户 无 须 提供 任何 额外 的 配置 。 它 的 使 用 格式 如 下 : 























spec: 
subresources: 
status: {} 





将 上 面 配置 清单 中 的 配置 片段 合并 人 至 前 面 创建 的 CRD 对 象 users 的 配 
置 中 ， 并 完成 活动 对 象 的 修改 即 可 在 其 实例 化 出 的 对 象 上 通过 /status 获 
取 状 态 信息 ， 如 对 象 admin 的 状态 引用 路 径 
为 /apis/auth.ilinux.io/vlbetal/namespaces/default/users/admin/status。 不 
过 ， 在 没有 相应 资源 控制 器 的 情形 下 ， 活 动 对 象 状态 的 非 计划 内 变动 既 
不 会 实时 反映 到 status 中 ， 也 不 会 癌 spec 定 义 的 期 望 状态 转换 。 


事实 上 ， 如 果 有 相应 的 资源 控制 器 维护 自 定义 的 资源 类 型 时 ， 还 可 
以 在 配置 自 定义 资源 对 象 时 使 用 scale 子 资源 和 status 子 资源 协同 实现 类 
似 Deployment 或 StatefulSet 等 控制 器 一 样 对 象 规模 的 伸缩 功能 。 它 的 定 
义 格式 如 下 : 








spec: 
status: {} 
scale: 
specReplicaspPath: 
statusReplicasPath: 
labelSelectorPath: 





需要 注意 的 是 ，scale 字 段 必须 与 status 字 上 段 一 起 使 用 ， 由 控制 器 通 
过 status 获 取 对 象 当 前 的 副本 数量 ， 并 与 spec 字 段 内 骨 套 的 用 于 指定 副本 
数量 的 字段 (例如 ， 常 用 的 replicas) 进行 比较 来 确定 其 所 需要 执行 的 伸 
缩 操作 ， 而 后 再 将 伸缩 操作 的 结果 更 新 至 status 字 段 中 。 上 面 的 配置 格 
式 中 ，scale 的 各 内 髓 字段 功用 说 明 具 体 如 下 。 


“specReplicasPath<string> : 引用 定义 在 spec 中 用 于 表示 期 望 的 副本 
数量 的 字段 ，JSONPath 格 式 ， 如 .spec.replicas。 


“statusReplicasPath<string> : 引用 保存 在 status 中 用 于 表示 对 象 的 当 
前 副本 数量 的 字段 ，JSONPath 格 式 ， 如 .status.replicas 。 


-labelSelectorPath<string> : 可 选 字段 ， 但 知 要 与 HPA 结 合 使 用 则 是 
必 选 字段 ， 用 于 引用 status 中 用 于 表示 使 用 的 标签 选择 器 字段 ， 
JSONPath 格 式 ， 如 .status.labelSelector。 


为 某 CRD 资 源 定义 scale 子 资源 之 后 ， 即 可 实例 化 出 文 持 规模 伸缩 的 
自 定 义 资源 对 象 。 但 必须 存在 一 个 相应 的 资源 控制 器 来 持续 维护 相应 的 
自 定 义 资源 对 象 ， 以 确保 其 当前 状态 匹配 期 望 的 状态 。 满 足 条 件 后 ， 关 
似 于 Deployment 资 源 对 象 等 ， 使 用 “kubectl scale” 命 令 就 能 完成 对 目 定 义 
资源 对 象 规 模 的 手动 伸缩。 








13.1.4 ”使 用 资源 类 别 


类 别 (categories) 是 Kubermetes 1.10 版 本 引入 的 一 种 分 组 组 织 自 定 
义 资源 的 方法 ， 定 义 CRD 对 象 时 为 其 指定 一 个 或 多 个 类 别 ， 可 以 通过 
kubectl get<category-name> 命 令 列 出 该 类 别 中 的 所 有 上 自 定 义 资源 对 象 ， 
al 就 是 一 个 常用 的 内 建 资 源 类 别 。 例 如 ， 为 前 面 定 义 的 CRD 对 象 users 的 
spec.names 字 上 段 中 额外 内 髋 如 下 配置 ， 便 能 使 得 users 资 源 类 型 下 的 所 有 
对 象 都 隶属 于 a 类 别 : 





spec: 
names: 
categories: 
- all 





categories 字 段 的 值 是 自 定 义 资源 所 属 的 分 组 资源 列表 。 而 后 ， 创 建 
的 所 有 自 定 义 类 型 users 的 对 象 都 能 够 通过 “kubectl get all” 命 令 进 行 获 
取 : 





~]$ kubectl1 get all 


NAME USERID GROUPS EMAIL 
user.auth.ilinux.io/admin 1 [superusers administrators] Kk8s@ilinux.io 


站 = 二 一 3 


13.1.5 ”多 版 本 支持 


Kubernetes 原 生 资 源 的 一 个 引 人 注 目的 特性 是 它们 能 够 在 API 版 本 之 
间 上 自动 和 透明 地 迁移 。 资 源 的 使 用 者 可 以 使 用 混合 API 版 本 ， 并 且 都 能 
获得 他 们 所 期 望 的 资源 版 本 。 而 自 Kubernetes 1.11 版 本 开始 ，CRD 支 持 
多 个 版 本 ， 但 它们 之 间 的 转换 必须 手动 完成 。 


在 CRD 上 使 用 多 版 本 机 制 时 ， 将 spec.version 字 段 蔡 换 为 
spec.versions 字 段 ， 并 将 文 持 的 各 版 本 以 对 象 列表 的 形式 给 出 定义 即 
可 。 不 过 ， 多 版 本 并 存 时 ， 仅 其 中 一 个 版 本 且 必 须 有 一 个 版 本 应 标记 为 
存储 〈spec.versions[].storage 字 段 ) 版 本 。 下 面 的 配置 清单 片断 中 定义 了 
两 个 API 版 本 ， 其 中 仅 vlbetal 标 记 为 了 storage: 











spec: 
versions: 

- name: vibetal 
served: true 
storage: true 

- name: vibeta2 
served: true 
storage: false 


将 上 述 配 置 清单 版 本 并 入 此 前 定义 的 users 资 源 配置 清单 中 并 应 用 于 
活动 对 象 后 再 创建 相应 美 型 的 自 定义 对 象 轩 就 可 以 通过 两 个 不 同 的 Al 
反 本 之 一 来 完成 。 





13.1.6_ 目 定义 控制 硕 基 础 


仅 借助 于 CRD 完 成 资源 目 定 义 本 映 并 不 能 为 用 户 带 来 太 多 的 价值 ， 

它 只 是 资源 类 型 的 定义 ， 只 是 提供 了 JSON 格 式 的 数据 范式 及 存 取 相关 
数据 的 能 力 ， 至 于 如 何 执行 数据 相关 的 业务 逻辑 ， 时 刻 确 保 将 status 中 
的 状态 移 回 spec 中 的 状态 则 是 由 封装 于 控制 器 中 的 代码 来 负责 实现 的 。 
相应 地 ， 为 自 定义 资源 类 型 提供 业务 逻辑 代码 的 控制 器 需要 由 用 户 自 行 
开发 ， 并 运行 为 API Server 的 客户 端 程序 (通常 是 托管 运行 于 Kubernetes 
系统 之 上 ， 类 似 于 Ingress 控 制 器 ) ， 这 就 是 所 谓 的 自 定义 控制 器 

(Custom Controller) 。 换 句 话 讲 ， 某 特定 的 CRD 资 源 的 相关 对 象 发 生 
变动 时 ， 如 何 确保 它 的 当前 状态 不 断 地 接近 期 望 的 状态 并 非 API Server 
的 功能 ， 而 是 相关 的 专用 控制 占 组 件 。 


事实 上 ， 自 定义 控制 器 不 仅仅 能 够 用 于 管理 CRD 资 源 ， 用 户 也 完全 
可 以 仅 针 对 系统 内 建 的 核心 类 型 对 象 开 发 更 高 级 别 的 控制 器 ， 这 些 对 象 
类 型 包括 Service、Deployment、ConfigMap 等 。 不 过 ， 对 于 每 个 CRD 的 
自 定 义 类 型 来 说 ， 至 少 应 该 存在 一 个 相关 的 自 定 义 控 制 器 ， 如 图 13-2 所 
示 。 
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图 13-2 ”Kubernetes 核 心 资源 与 CRD 


简单 来 说 ， 控 制 器 负责 持续 监视 资源 变动 ， 根 据 资源 的 spec 及 status 
中 的 信息 执行 某 些 操作 逻辑 ， 并 将 执行 结果 更 新 至 资源 的 status 中 。 目 
定义 控制 器 同样 担负 着 类 似 的 职责 ， 只 不 过 一 个 特定 的 控制 器 通常 仅 负 
责 管理 一 部 分 特定 的 资源 类 型 ， 并 执行 专 有 管理 逻辑 。 


Kubernetes 系 统 内 建 了 许多 控制 器， 如 NodeController、 
ServiceController 等 ， 它 们 打包 在 一 起 并 作为 一 个 统一 守护 进程 kube- 
controller-manager。 这 些 控制 器 基本 上 都 遵循 同一 种 模式 以 完成 资源 管 
理 操 作 ， 该 模式 通 第 可 摘 述 为 三 种 特性 : 声明 式 API、 有 异步 和 水 平 式 处 
理 。 


.声明 式 API: 用 户 定 义 期 望 的 状态 而 非 要 执行 的 特定 操作 ， 如 使 用 
kubectl apply 命 令 将 请 求 发 送 至 API Server 存 储 于 etcd 中 ， 并 由 API Server 
做 出 处 理 响应 。 


.异步 : 客户 端的 请 求 于 API Server 存 储 完成 之 后 即 返 回 成 功 信息 ， 
而 无 须 等 待 控制 占 执 行 的 和 解 循环 结束 。 


:水平 式 处 理 (level-based) : 同一 对 象 有 多 次 变动 事件 待 处 理 时 ， 
控制 器 仅 需 要 人 处理 其 最 新 一 次 的 变动 。 这 种 根据 最 新 观察 结果 而 非 历 史 
变化 来 和 解 status 和 spec 的 机 制 即 为 水 平 式 处 理 机 制 。 


自 定义 控制 占 实 现 自 定义 资源 管理 行为 的 最 佳 方 法 同样 是 遵循 此 类 
控制 器 模式 进行 程序 开发 ， 目 前 ， 大 部 分 开发 接口 都 是 基于 Golang 语 言 
来 实现 的 ， 相 关 代 码 位 于 客户 端 库 的 client-go/go/tools/cache 和 client- 
gomtil/workqueue 目 录 中 。 


简单 来 说 ， 控 制 器 包含 两 个 重要 组 件 : Informer/SharedInformer 利 


Workqueue， 前 者 负责 监视 资源 对 象 当前 状态 的 更 改 ， 并 将 事件 发 送 至 
后 者 ， 而 后 由 处 理 函 数 进 行 处 理 ， 如 图 13-3 所 示 。 
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Informer Queue Controller 
ListWatch.ListFunc namespace/name queue.Get 
ListWatch.WatchFunc ee if created: 
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AddFunc namespace/name if deleted: 
UpdateFunc namespace/name ObjectDeleted 
DeleteFunc -一 一 一 
namespace/name 





图 13-3 ”处 理 器 事件 流动 示意 图 (图 片 来 
源 : https://medium.com/@trstringer ) 


Informer 主 要 由 Listwatcher、ResourceEventHandler 和 ResyncPeriod 三 
类 函数 组 件 进行 构造 。 


:Listwatcher 是 应 用 于 特定 名 称 空间 中 特定 资源 对 象 的 列表 函数 
(listFunc) 和 监视 函数 (watchFunc) ， 并 结合 字段 选择 器 为 控制 器 精 
确 限 定 关注 的 资源 对 象 。 


.ResourceEventHandler 负 责 处 理 资源 对 象 状 态 改 变 产 生 的 相关 通 
知 ， 其 分 别 使 用 AddFunc、UpdateFunc 和 DeleteFunc 三 个 函数 完成 对 象 
的 创建 、 更 新 和 删除 操作 。 


ResyncPeriod 定 义 控制 右 遍 历 缓存 中 的 所 有 项 目 并 触发 运行 
UpdateFunc 的 频率 ， 即 和 解 循环 的 执行 频 度 。 较 高 的 频 度 对 于 控制 器 错 
过 某 次 更 新 或 此 前 的 更 新 操作 执行 失败 时 非常 有 用 ， 但 会 对 系统 资源 这 
来 较 高 的 压力 ， 因 此 具体 的 时 长 需要 全 面 、 系 统 地 进行 权衡 。 


Informer 是 控制 器 的 私有 组 件 ， 它 为 相关 资源 对 象 创 建 的 缓存 信息 








仅 可 供 当 前 控制 器 使 用 。 而 在 Kubernetes 系 统 上 ， 同 一 资源 对 象 支持 多 
个 控制 器 共同 处 理 ， 而 且 多 个 控制 器 监视 同一 资源 对 象 也 是 较为 常见 的 
情形 ， 于 是 ， 一 个 更 高 效 的 方式 是 使 用 蔡 代 解决 方案 SharedInformer 和 和 

Workqueue。 SharedInformer 支 持 在 监控 同类 资源 对 象 的 控制 器 之 则 创建 
共享 缓存 ， 这 有 效 降 低 了 内 存 资源 开销 ， 而 且 它 也 仪 需要 在 上 游 的 API 
Server 中 注册 创建 一 个 监视 器 ， 即 能 显 井 减轻 上 游 服 务 吉 的 访问 压力 。 

因此 ， 较 之 Informer，SharedInformer 才 是 更 为 常用 的 解决 方案 。 


不 过 ，SharedInformer 无 法 跟 踩 每 个 控制 器 的 位 置 〈 因 为 它 是 共享 
的 ) ， 于 是 控制 右 必 须 负 责 提 供 上 自用 的 工作 队列 及 重 试 机制 ， 这 也 意味 
着 它 的 ResourceEventHandler 程 序 只 是 将 事件 放 在 每 个 消费 者 的 
Workqueue 中 。 


.每 当 资 源 发 生变 化 时 ，ResourceEventHandler 程 序 都 会 将 一 个 键 放 
入 工作 队列 中 ， 对 于 名 称 空间 级 别 资源 对 象 的 相关 事件 ， 其 键 名 格式 为 
<resource_namespace>/<resource_name>， 和 集群 级 别 资源 对 象 的 键 名 则 只 
包含 <resource_name>。 


目前 ， 工 作 队 列 存在 延迟 队列 、 定 时 队列 和 速率 限制 队列 等 几 种 


形式 。 


因此 ， 目 定义 控制 喜 构 建 起 来 存在 一 定 的 复杂 度 。 实 践 中 ， 为 了 便 
于 用 户 使 用 client-go 创 建 控 制 器 ，Kubernetes 社 区 发 布 了 模板 类 的 项 目 
workqueue example 和 sample-controller， 它 们 提供 了 一 个 自 定 义 控制 器 项 
目 应 有 的 基础 结构 。 通 常 的 做 法 是 复制 相应 的 代码 并 按 需 修改 相应 的 部 
分 ， 例 如 ， 将 syncHandler 修 改 为 自 定 义 资 源 类 型 业务 处 理 逻 辑 等 ， 而 后 
借助 于 code-generator 项 目 用 脚本 完成 相应 的 组 件 ， 如 typed clients、 
informers 等 。 虽 然 好 过 从 堆 构 建 自 定义 控制 器 的 代码 ， 但 这 类 方式 总 觉 
得 有 些 不 趁 手 和 美中不足 。 


好 在 ， 现 在 已 经 有 了 几 类 更 加 成 熟 、 更 易 上 手 的 工具 可 用 ， 它 们 其 
至 已 经 可 以 被 视 作 开发 CRD 和 控制 器 的 SDK 或 框架 ， 其 中 ， 主 流 的 项 目 
主要 有 Kubebuilder、Operator SDK 和 Metacontroller 三 个 。Kubebuilder 主 
要 由 Google 的 工程 师 Phillip Wittrock 创 立 ， 但 目前 归属 于 SIG API 
Machinery， 有 和 较 完 善 的 在 线 文 档 。Operator SDK 是 CoreOS 发 布 的 开源 
项 目 ， 是 Operator Framework 的 一 个 子 集 ， 其 出 现时 间 略 早 ， 社 区 接受 
度 较 高 ， 以 致 很 多 人 干脆 就 把 自 定 义 控 制 器 与 Operator 当 作 同 一 事物 不 
加 区 分 地 使 用 ， 目 前 已 经 有 etcd、Prometheus、Rook 和 Vault 几 个 成 熟 的 









































Operator 可 用 。Metacontroller 由 GCP 友 布 ， 与 前 两 者 的 区 别 较 大 ， 它 将 
控制 器 模式 直接 委托 给 Metacontroller 框 架 ， 并 调用 用 户 提 供 的 WebHook 
实现 模式 的 处 理 功能 ， 文 持 任何 编程 语言 开发 ， 接 收 并 返回 JSON 格 式 
的 序列 化 数据 。 


13.2 ”上 和 目 定 义 API Server 


扩展 Kubernetes 系 统 API 接 口 的 男 一 种 常用 办 法 是 使 用 自 定义 的 API 
Server。 相 较 于 CRD 来 说 ， 使 用 自 定义 API Server 更 加 灵活 ， 例 如 可 以 自 
定义 资源 类 型 和 子 资源 、 目 定义 验证 及 其 他 逻辑 ， 甚 至 于 在 Kubernetes 
API Server 中 实现 的 任何 功能 也 都 能 在 自 定义 API Server 中 实现 。 


13.2.1 上 自 定 义 API Server 概 述 





自 定 义 API Server 完 全 可 以 独立 运行 并 能 够 被 客户 端 直 接 访问 ， 但 
最 方便 的 方式 是 将 它们 与 主 API Server (kube-apiserver) 聚合 在 一 起 使 
用 ， 这 样 不 仅 可 以 使 得 集群 中 的 多 个 API Server 看 起 来 好 像 是 由 单个 服 
务 器 提供 服务 ， 和 集群 组 件 和 kubectl 等 客户 端 可 不 经 修改 地 继续 正常 通 
信 ， 而 且 也 无 须 特 殊 逻 辑 来 发 现 不 同 的 API Server 等 操作 。 在 kube- 
apiserver 中 ， 用 于 聚合 自 定义 API Server 的 组 件 是 kube-aggregator， 它 自 
Kubernetes 1.7 版 本 引入 ， 并 内 建 于 主 API Server 之 中 作为 其 进程 的 一 部 
分 来 运行 ， 如 图 13-4 所 示 。 
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图 13-4” 自 定义 API 服 务 器 及 APIService 资 源 


在 使 用 自 定义 API Server 中 的 扩展 资源 之 前 ， 管 理 员 需要 在 主 API 
Server 上 添加 一 个 相应 的 APIService 资 源 对 象 ， 将 目 定 义 API Server 注 册 
到 kube-aggregator 之 上 ， 以 完成 聚合 操作 。 一 个 特定 的 APIService 对 象 可 
用 于 在 主 API Server 上 注册 一 个 URL 路 径 ， 

如 /apis/auth.ilinux.io/vlbetal/， 从 而 使 得 kube-aggregator 将 发 往 这 个 路 径 
的 请 求 代 理 至 相应 的 自 定 义 API Server。 每 个 APIService 对 应 于 一 个 API 
群 组 版 本 ， 不 同 版 本 的 单个 API 可 以 由 不 同 的 APIService 对 象 支持 ， 如 
图 13-5 所 示 。 
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图 13-5 ”Kubernetes 聚 合 层 及 其 聚合 方式 


相对 于 CRD 和 上 自 定义 控制 器 来 说 ， 开 发 自 定 义 API Server 要 复杂 得 
多 ，Kubernetes 为 此 也 提供 了 专用 的 构建 聚合 API Server 的 通用 库 ， 项 目 
名 称 就 叫 作 apiserver。apiserver 开 发 库 包 含 了 用 于 创建 Kubernetes 聚 合 服 
务 器 的 基础 代码 ， 其 中 包含 委派 的 authentication 和 authorization， 以 及 
kubectl 兼 容 的 发 现 机 制 、 可 选 的 许可 控制 链 (admission chain ) 和 版 本 
化 类 型 (versioned type) 等 ， 同 时 ， 它 还 有 一 个 示例 性 的 项 目的 sample- 
apiserver 可 用 作 开 发 模板 。 不 过 ， 目 前 最 好 的 实践 方式 是 借助 于 专用 于 
构建 聚合 服务 器 的 项 目 apiserver-builder 进 行 开发 ， 它 提供 了 基于 
apiserver 代 但 构建 原生 Kubernetes 扩 展 资源 的 开发 库 和 开发 工具 的 集 


器 o 





但 创建 自 定义 API Server 需 要 编写 大 量 的 代码 ， 而 且 每 个 自 定 义 的 
API Server 都 需要 上 自行 管理 所 使 用 的 存储 系统 ， 它 们 可 使 用 自 有 的 etcd 存 
储 服务 ， 也 可 通过 CRD 将 资源 数据 存储 于 主 API Server 的 存储 系统 中 ， 
但 此 场景 需要 事先 创建 依赖 到 的 所 有 自 定 义 资 源 。 除 非特 别 需 要 创建 自 
定义 的 API Server， 否 则 还 是 建议 读者 选择 使 用 Kubebuilder 直 接 基 于 
CRD 和 自 定义 控制 器 进行 系统 扩展 。 


13.2.2 APIService 对 象 





APIService 资 源 类 型 的 最 初 设计 目标 是 用 于 将 庞大 的 主 API Server 分 
解 成 多 个 小 型 但 彼此 独立 的 API Server， 但 它 也 支持 将 任何 遵循 
Kubernetes API 设 计 规 范 的 自 定 义 API Server 聚 合 进 主 API Server 中 。 


下 面 的 配置 清单 示例 取 自 sample-apiserver 项 目 ， 它 定义 了 一 个 名 为 
V2betal.auth.ilinux.io 的 APIService 对 象 ， 用 于 将 default 名 称 空 间 中 名 为 
auth-api 的 Service 对 象 后 端的 自 定义 API Server 聚 合 进 主 API Server 中 : 





apiVersion: apiregistration.k8s.io/vibetal 
kind: APIService 
metadata: 
name: v2betal.auth.ilinux.io 
spec: 
insecureSkipTLSVerify: true 
group: auth.ilinux.io 
groupPriorityMinimum: 1000 
versionpPriority: 15 
service: 
name: auth-api 
namespace: default 
version: v2betal 





定义 一 个 APIService 对 象 时 ， 其 Spec 扔 套 使 用 的 字段 包括 如 下 这 些 
字段 。 


"group<string>: 注册 使 用 的 API 群 组 名 称 。 

groupPriorityMinimum<integer>: API 群 组 的 最 低 优先 级 ， 较 高 优 
先 级 的 群 组 将 优先 被 客户 端 使 用 ;数值 越 大 优选 级 越 高 ， 数 值 相同 时 则 
按 名 称 字符 进行 排序 。 

Version<string>: 注册 的 API 群 组 的 版 本 。 

:VersionPriority<integer>: 当前 版 本 在 其 所 属 的 API 群 组 内 的 优先 
级 ; 必须 使 用 正 整 数 数 值 ， 数 值 越 大 优先 级 越 高 ， 数 值 相同 时 则 按 名 称 
字符 进行 排序 。 


“service<Object>: 目 定 义 API Server 相 关 的 Service 对 象 ， 是 真正 提 


供 API 服 务 的 后 端 ， 它 必须 通过 443 端 口 进行 通信 。 


:caBundle<string>: PEM 编 码 的 CA 打包 信息 ， 用 于 验证 API service 
的 服务 证 书 。 


.insecureSkipTLSVerify<boolean>: 与 此 服务 通信 时 是 否 禁 止 TLS 证 
书 认证 。 


APIService 仅 用 于 将 API Server 进 行 聚 合 ， 真 正 提 供 服 务 的 是 相应 的 
外 部 API Server， 这 个 自 定义 服务 右 通 常 应 该 以 Pod 的 形式 托管 运行 于 当 
前 Kubernetes 集 群 之 上。 于 是 ， 在 Kubernetes 集 群 上 部 署 使 用 自 定 义 API 
Server 主 要 由 两 步 组 成 ， 首 先 需要 将 自 定 义 API Server 以 Pod 形 式 运 行 于 
集群 之 上 并 为 其 创建 Service 对 象 ， 而 后 创建 一 个 专用 的 APIService 对 象 
与 主 API Server 完 成 聚合 。Kubemetes 系 统 的 系统 资源 指标 API 就 由 
metrics-server 项 目 提供 ， 该 项 目 基 于 metrics-server 提 供 了 一 个 扩展 的 
API， 并 通过 API 群 组 metrics.k8s.io 将 其 完成 聚合 ， 后 文中 资源 指标 及 监 
控 相 关 的 章节 将 讲述 相关 的 部 署 及 使 用 方法 。 





13.3 ”Kubernetes 集 和 群 高 可 用 


Kubernetes 具 有 目 您 能 力 ， 当 它 跟 踪 到 某 工 作 节点 发 生 故 障 时 ， 控 
制 平 面 可 以 将 离线 节点 上 的 Pod 对 象 重新 编排 至 其 他 可 用 的 工作 节点 上 
运行 ， 因 此 ， 更 多 的 工作 节点 也 就 意味 着 更 好 的 容错 能 力 ， 因 为 它 使 得 
Kubernetes 在 实现 工作 节点 故障 转移 时 拥有 更 加 灵活 的 自由 度 。 而 当 管 
理 员 检测 到 集群 负载 过 重 或 无 法 容纳 其 更 多 的 Pod 对 象 时 ， 通 弟 需 要 手 
动 将 节点 添加 到 集群 ， at Kubernetes cluster-autoscaler 还 
为 集群 提供 了 规模 按 需 目 动 缩放 的 能 


然而 ， 添 加 更 多 的 工作 节点 并 不 能 使 集群 适应 各 种 故障 ， 例 如 ， 若 
主 API 服 务 右 出 现 故 障 〈( 由 于 其 主机 出 现 故障 或 网 络 分 区 将 其 从 集群 中 
隔离 ) ， 则 其 将 无 法 再 跟踪 和 控制 集群 。 因 此 ， 还 需要 元 余 控制 平面 的 
各 组 件 以 实现 主 节 点 的 服务 高 可 用 性 。 基 于 元 余数 量 的 不 同 ， 控 制 平面 
能 容忍 一 个 甚至 是 多 个 节点 的 故障 。 一 般 来 说 ， 高 可 用 控制 平面 至 少 需 
要 三 个 Master 节 点 来 承受 最 多 一 个 Master 节 点 的 丢失 ， 才 能 保证 等 待 状 
态 的 Master 节 点 能 够 保持 半数 以 上 ， 以 满足 节点 选举 时 的 法 定 票 数 。 一 
个 最 小 化 的 Master 节 点 高 可 用 染 构 如 图 13-6 所 示 。 
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图 13-6 “最 小 化 Master 节 点 高 可 用 架构 




















Kubernetes 组 件 中 仪 etcd 需 要 复杂 逻辑 完成 集群 功能 ， 其 他 组 件 间 
的 松 耦 合 特性 使 得 系统 能 够 通过 多 种 方式 实现 Master 节 点 的 高 可 用 性 ， 
和 
， 有 其 体 如 下 。 


利用 etcd 目 身 提 供 的 分 布 式 存储 集群 为 Kubernetes 构 建 一 个 可 靠 的 
存储 层 。 


-将 无 状态 的 apiserver 运 行为 多 副本 ， 并 在 其 前 端 使 用 负载 均衡 占 调 
度 请 求 ， 需 要 注意 的 是 ， 负 载 均衡 器 本 身 也 需要 是 高 可 用 的 。 


多 副本 的 控制 器 省 理 右 ， 通 过 其 自 禹 的 leader 选 举 功 能 (--leader- 
election) 选举 出 主角 色 ， 余 下 的 副本 在 主角 色 发 生 故 障 时 自动 局 动 新 一 
轮 的 选举 操作 。 


副本 的 调度 器， 通过 其 自 带 的 leader 选 举 功 能 (--leader- 
election) 选举 出 主角 色 ， 余 下 的 副本 在 主角 色 发 生 故 障 时 自动 启动 新 一 
轮 的 选举 操作 。 











13.3.1 ”etcd 高 可 用 





分 布 式 服务 之 间 进 行 可 靠 、 高 效 协作 的 关键 前 提 是 有 一 个 可 信 的 数 
据 存 储 和 共享 机 制 ，etcd 项 目 正 是 致力 于 此 目的 构建 的 分 布 式 数据 存储 
系统 ， 它 以 键 值 格式 组 织 数 据 ， 主 要 用 于 配置 共享 和 服务 发 现 ， 也 文 持 
实现 分 布 式 锁 、 集 群 监控 和 leader 选 举 等 功能 。 


etcd 基 于 Go 语言 开发 ， 内 部 采用 raft 协 议 作 为 共识 算法 进行 分 布 式 
协作 ， 将 数据 同步 存储 在 多 个 独立 的 服务 实例 上 以 提高 数据 的 可 靠 性 ， 
从 而 避免 了 单 点 故障 所 导致 的 数据 丢失 。Raft 协 议 通 过 选举 出 的 leader 节 
点 来 实现 数据 的 一 致 性 ， 由 leader 节 点 负责 所 有 的 写 入 请 求 并 同步 给 集 
群 中 的 所 有 节点 ， 在 取决 半数 以 上 follower 节 点 的 确认 后 予以 持久 存 
储 。 这 种 需要 半数 以 上 节点 投票 的 机 制 要 求 集群 数量 最 好 是 奇数 个 市 
点 ， 推 荐 的 数量 为 3 个 、5 个 或 7 个 。etcd 集 群 的 建立 有 三 种 方式 ， 有 具体 如 
下 


-静态 集群 ， 事 移 规划 并 提供 所 有 节点 的 固定 耳 地 址 以 组 建 集群 ， 
A 好 处 是 它 不 依赖 于 任 
何 外 部 服务 。 


.基于 etcd 发 现 服务 构建 集群 : 通过 一 个 事先 存在 的 etcd 和 集群 进行 服 
1 支持 集群 的 动态 构建 ， 它 依赖 于 一 个 现存 可 用 的 
etcd 服 务 。 


基于 DNS 的 服务 资源 记录 构建 集群 : 通过 在 DNS 服务 上 的 茶 域 名 
下 为 每 个 节点 创建 一 条 SRV 记 录 ， 而 后 基于 此 域名 进行 服务 发 现 来 动态 
组 建新 集群 ， 它 依赖 于 DNS 服务 及 事先 管理 妥当 的 资源 记录 。 


一 般 说 来 ， 对 于 etcd 分 布 式 存储 集群 来 说 ， 三 节点 集群 可 容错 一 个 
节点 ， 五 节点 集群 可 容错 两 个 节点 ， 七 节点 集群 可 容错 三 个 贡 氮 ， 依 次 
类 推 ， 但 通常 来 说 ， 多 于 七 个 节点 的 集群 规模 是 没有 必要 的 ， 而 且 对 系 
统 性 能 也 会 产生 负面 影响 。 























13.3.2 ”Controller Manager 和 Scheduler 高 可 用 





Controller Manager 通 过 监控 API Server 上 的 资源 状态 变动 并 按 需 分 
别 执行 相应 的 操作 ， 于 是 ， 多 实例 运行 的 kube-controller-manager 进 程 可 
能 会 导致 同一 操作 行为 被 每 一 个 实例 分 别 执行 一 次 ， 例 如 ， 某 一 Pod 对 
象 创建 的 请 求 被 3 个 控制 器 实例 分 别 执行 一 次 进而 创建 出 一 个 Pod 对 象 副 
本 来 。 因 此 ， 在 某 一 时 刻 ， 仅 能 有 一 个 kube-controller-manager 实 例 处 于 
正常 工作 状态 ， 余 下 的 均 处 于 备用 状态 ， 或 者 称 为 等 竺 状态。 


多 个 kube-controller-manager 实 例 要 同时 启用 “--leader-elect=true” 选 
项 以 自动 实现 leader 选 举 ， 选 举 过 程 完成 后 ， 仪 leader 实 例 处 于 活动 状 
态 ， 余 下 的 其 他 实例 均 转 入 等 待 模式， 它们 会 在 探测 到 leader 故 障 时 进 
行 新 一 轮 的 选举 。 与 etcd 集 群 基于 raft 协 议 进行 leader 选 举 不 同 的 是 ， 
kube-controller-manager 集 群 各 目的 选举 操作 仅 是 通过 在 kube-system 名 称 
空间 中 创建 一 个 与 程序 同名 的 Endpoints 资 源 对 象 来 实现 : 











~]$ kubectl get endpoints -n kube-system 

NAME ENDPOINTS AGE 
kube-controller-manager <none> 13h 
kube-scheduler <none> 13h 





这 种 leader 选 举 操作 是 分 布 式 锁 机 制 的 一 种 应 用 ， 它 通过 创建 和 维 
护 Kubernetes 资 源 对 象 来 维护 锁 状 态 ， 目 前 Kubernetes 文 持 ConfigMap 和 
Endpoints 两 种 类 型 的 资源 锁 。 初 始 状态 时 ， 各 kube-controller-manager 实 
例 通 过 竞争 的 方式 去 抢占 指定 的 Endpoints 资 源 锁 。 胜 利 者 将 成 为 
leader， 它 通过 更 新 相应 的 Endpoints 资 源 的 注解 control- 
plane.alpha.kubernetes.io/leader 中 的 “holderIdentity” 为 其 节点 名 称 ， 从 而 
将 自己 设置 为 锁 的 持 有 者 ， 并 基于 周期 性 更 新 同一 注解 中 
的 “renewTime” 以 声明 自己 对 锁 资 源 的 持 有 状态 从 而 避免 等 待 状态 的 实 
例 进行 搜 抢 。 于 是 ， 一 旦 某 leader 不 再 更 新 renewTime 了 ， 等 竺 状态 的 各 
实例 就 将 一 哄 而 上 进行 新 一 轮 的 竞争 。 








~]$ kubect1 describe endpoints kube-controller-manager -n kube-system 


Name : kube-controller-manager 
Namespace: kube-system 
Labels: <none> 


Annotations: control-plane.alpha.kubernetes.io/leader={"holderIidentity":"masteri. 


ilinux.io_846a3ce4-b0b2-11e8-9a23-00505628fa03", "leaseDurationSeconds":15,"acquj 
"2018-09-05T02:22:542Z", "renewTime":"2018-09-05T02:40:552Z", "leaderTransitions":1) 
Subsets: 
Events: 
Type Reason Age From Message 
Normal LeaderElection 13h kube-controller-manager master0.ilinux.io_e8fca6fc- 
b049-11e8-a247-000c29abgof5b became leader 
Normal LeaderElection 5m kube-controller-manager master1.ilinux.io 846- 
a3ce4-bob2-11e8-9a23-00505628fa03 became leader 








kube-scheduler 的 实现 方式 与 此 类 似 ， 只 不 过 它 使 用 的 是 自己 专用 的 
Endpoints 资 源 kube-scheduler。 


@ 提示 “基于 kubeadm 部 署 高 可 用 集群 的 方式 可 参考 文 
档 https://kubernetes.io/docs/setup/independent/high-availability/ 给 出 的 步 
又 来 进行 。 


13.4 Kubernetes 的 部 署 模式 


Kubernetes 在 容器 生态 系统 的 快速 增长 过 程 中 形成 了 多 种 部 署 模 
式 ， 包 括 目 助 式 、 目 托管 式 和 完全 上 自动 化 等 多 种 管理 形式 的 集群 。 无 论 
部 署 方式 如 何 ， 开 发 人 员 和 运营 团队 都 要 遵循 标准 化 、 一 致 的 工作 流程 
来 管理 容器 化 应 用 程序 的 生命 周期 ， 这 也 恰 是 Kubernetes 的 关键 优势 之 





实践 中 ，Kubernetes 的 客户 可 以 使 用 各 种 各 样 的 部 团 模 型， 包括 对 
开 有 友人 员 友 好 的 PaaS 模 型 以 及 高 度 目 定 义 的 运行 于 裸 服务 器 的 部 署 模 
型 ， 等 等 ， 其 中 的 每 种 模式 都 有 其 优 缺 点 。 通 常 ， 将 容器 部 普 到 本 地 服 
务 器 时 ， 数 据 的 持久 存储 是 最 大 的 挑战 ， 而 对 于 那些 部 闭 到 云 环 境 的 模 
型 来 说 ， 引 用 监视 和 日 志 记 录 则 是 其 最 大 的 挑战 。 男 外 ， 安 全 性 是 任何 
Kubernetes 部 署 模 型 的 核心 因素 ， 任 何 部 署 操作 从 设计 时 束 应 该 充分 考 
虚 到 其 安全 性 。 


本 节 主 要 摘 述 Kubermmetes 系 统 较 为 常用 的 部 昔 模 型 ， 以 帮助 读者 理 
解 其 部 署 选项 ， 与 每 个 选项 相关 的 挑战 和 考虑 因素 ， 以 及 在 其 中 运行 生 
产 型 工作 负载 的 管理 模型 。 














13.4.1 关键 组 件 


生产 可 用 的 部 署 方 案 中 ， 除 了 Kubernetes 之 外 ， 还 有 多 个 对 生产 集 
ee 如 镜像 仓库 、 监 控 系 统 、 日 志 系 统 等 ， 如 图 
13-7 所 不 。 
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Core Infrastructure 
(Physical/Virtual/Public Cloud/Private Cloud) 
图 13-7 Kubermnetes 集 群 的 关键 组 件 


1) 核心 基础 架构 : 此 为 Kubernetes 集 群 的 基础 设施 组 件 ， 用 于 提供 
文 持 容 器 化 工作 负载 的 计算 、 网 络 及 存储 相关 的 撒 层 部 件 ， 它 们 可 能 是 
物理 服务 器 、 虚 拟 化 数据 中 心 、IaaS 类 型 的 私有 云 或 公有 云 。 


2) 车 加 网 络 : Kubernetes 基 于 SDN (Software-Defined 
Networking) 提供 的 网 络 环境 实现 内 部 通信 ， 它 将 用 于 确保 集群 的 所 有 
内 部 组 件 都 能 够 正常 通信 ， 可 以 选用 的 项 目 包含 诸如 Calico、Flannel、 
Romana 和 Weave Net 等 ， 这 在 前 面 的 章节 中 已 经 有 过 详细 的 讲解 。 


3) 存储 系统 : 运行 有 状态 的 工作 负载 (如 数据 库 ) 时 ， 持 久 化 数 
据 存 储 是 必 备 的 组 件 。SDS (Software-Defined Storage) 层 即 作为 持久 
存储 卷 暴 露 给 容器 ， 分 布 式 存储 软件 如 GlusterFS、 网 络 文件 系统 
(NFS) 和 块 级 别 存 储 卷 RBD 等 ) 是 首选 。 














4) Kubernetes 集 群 ， 由 控制 平面 Master 节 点 、 分 布 式 键 值 存储 系统 
etcd 和 工作 节点 组 成 。 主 节点 负责 工作 负载 的 调度 和 编排 ， 主 要 由 API 
服务 器 、 控 制 器 管理 器 和 调度 器 组 成 。 它 们 是 Kubernetes 集 群 的 控制 中 
心 ， 生 产 环 境 中 需要 宛 余 化 配置 以 确保 服务 的 可 用 性 。etcd 存 储 系统 负 
责 维 护 集群 和 工作 负载 的 当前 状态 ， 鉴 于 其 重要 性 通常 需要 为 其 配置 分 
布 式 环境 以 实现 元 余 和 高 可 用 性 。 各 工作 节点 负责 运行 工作 负载 ， 在 云 
计算 环境 中 此 部 分 可 由 Cluster AutoScaler 实 现 弹性 伸缩 。 


5) 容器 化 工作 负载 : 于 Kubernetes 集 群 内 部 署 的 应 用 程序 ， 其 中 一 
部 分 有 可 能 需要 暴露 给 集群 外 部 的 客户 端 程序 。 


6) 供应 和 配置 管理 : 安装 和 配置 Kubernetes 集 群 与 部 署 高 度 可 用 的 
关键 型 分 布 式 应 用 程序 并 无 太 大 区 别 。 为 了 确保 一 至 性 和 可 重复 性 ， 通 
币 应 该 依赖 于 工具 链 的 实现 ， 类 似 Ansible、Chef、Puppet、Terraform 和 
其 他 自动 化 工具 。 这 些 工 具 使 得 升级 、 修 补 和 维护 Kubernetes 基 础 架构 
变 得 更 加 容易 。 


7) 镜像 仓库 : 运行 容器 化 应 用 程序 时 ，Kubernetes 节 点 需要 事先 从 
镜像 仓库 中 提取 相应 的 容器 镜像 。 在 每 次 提交 代码 时 上 自动 构建 新 镜像 的 
环境 中 ， 应 用 程序 将 自动 升级 为 最 新 版 本 的 镜像 。 为 了 减少 延迟 并 提高 
安全 性 ， 镜 像 应 该 存储 在 托管 于 集群 之 上 的 仓库 服务 中 。 


8) 日 志 记 录 和 监控 : 分 布 式 应 用 程序 会 生成 大 量 日 志 ，Kubernetes 
也 不 例外 。 集 群 中 的 每 个 组 件 〈 包 括 已 部 署 的 应 用 程序 ) 都 会 生成 需要 
捕获 和 处 理 的 日 志 ， 它 们 对 故障 排 得 和 监视 群集 活动 有 着 不 可 蔡 代 的 作 
用 。 日 志 与 监控 工具 结合 使 用 ， 有 助 于 深入 了 解 集群 的 运行 状态 ， 和 用 
的 实现 有 如 Elastic Stack、Grafana 和 Prometheus 等 。 该 层 是 生产 部 署 的 重 
要 组 成 部 分 。 


9) 负载 均衡 器 : Kubernetes 集 群 有 两 处 位 置 依赖 于 负载 均衡 器 ， 它 
们 分 别 是 API 服 务 器 和 公共 类 型 的 容 句 化 应 用 。 配 置 了 高 可 用 服务 的 
Master 市 点 上 ，API 服 务 器 经 负载 均衡 如 调度 以 承载 更 多 的 用 户 请 求 ， 
而 提供 公共 服务 的 应 用 程序 运行 于 多 个 Pod 对 象 并 辐 集 群 外 部 暴露 时 也 
需要 负载 均衡 器 。 


10) 工件 仓库 : 工件 仓库 用 于 维护 属于 应 用 程序 的 资产 ， 尤 其 是 随 
独 分 布 式 应 用 程序 复杂 性 的 增长 ， 需 要 管理 的 程序 资产 包括 各 种 配置 设 
定 、 依 赖 项 、 软 件 包 、 脚 本 ， 甚 至 是 二 进 制 文件 。 在 某 些 情况 下 ， 工 件 









































仓库 本 里 甚至 也 具有 镜像 仓库 的 功能 。 


11) 构建 和 发 布 管理 : 随 着 持续 集成 和 持续 交付 成 为 应 用 程序 生命 
周期 管理 CALM) 的 首选 机 制 ， 构 建 和 发 布 目 动 化 正在 成 为 IT 组 织 核心 
文化 ， 实 现 此 关 功 能 的 目 动 化 工具 通过 高 效 的 流水 线 来 连接 源 代 码 管理 
系统 和 生产 环境 。 








13.4.2 ”各 见 的 部 署 模 式 


Kubernetes 是 近来 最 为 成 功 的 开源 项 目 之 一 ， 在 CNCF 的 主导 下 ， 它 
得 到 了 来 自 于 CoreOS、Google、 华 为 、IBM、RedHat 和 中 兴 通 讯 等 公司 
程序 员 的 积极 贡献 ， 源 代码 质量 较 高 且 经 过 了 社区 的 严格 评估 ， 托 管 于 
GitHub 之 上 的 代码 仓库 中 的 主干 代码 可 直接 用 于 部 署 生产 环境 。 不 过 ， 
据 CNCF 于 2017 年 秋季 的 调查 显示 ， 实 施 的 复杂 性 仍 是 许多 组 织 不 使 用 
Kubernetes 的 主要 原因 之 一 。 


笠 运 的 是 ，Kubernetes 项 目 在 日 渐 成 熟 的 过 程 中 ， 社 区 为 系统 的 安 
装 简化 也 正在 倾 力 而 为 。 尽 管 该 软件 的 初始 版 本 安装 起 来 依然 稍 显 复 
杂 ， 但 借助 于 kubeadm 之 类 的 工具 已 然 能 够 使 得 普通 的 系统 管理 员 也 可 
以 较为 轻松 地 部 团 Kubernetes， 本 书 使 用 的 也 正 是 这 种 部 署 方式 。 男 
外 ， 诸 如 Cloud Foundry Container Runtime、Canonical conjure-up 和 kops 
2 a 性 也 使 得 Kubernetes 在 数据 中 心 和 公有 云 环境 中 的 部 蜀 变 
得 更 加 简单 。 


于 是 ， 自 定义 或 自主 托管 Kubernetes 部 署 的 模式 正在 受到 越 来 越 多 
人 的 关注 ， 基 于 此 种 方式 ， 用 户 可 以 在 物理 服务 器 、 虚 拟 机 和 云 计算 环 
境 中 进行 系统 部 署 ， 其 配置 方式 和 部 署 体 验 据 所 用 工具 的 不 同 而 有 所 不 
同 。 


自 定 义 的 部 署 模式 为 用 户 的 终极 部 署 机 制 ， 他 们 可 以 从 众多 的 目标 
部 署 环境 、 机 器 配置 、 操 作 系 统 、 存 储 后 端 、 网 络 插件 和 高 可 用 性 配置 
中 进行 选择 。 当 然 ， 在 提供 多 样 性 选择 和 控制 的 同时 ， 维 护 集群 的 责任 
将 全 部 给 系 于 用 户 目 号 。 因此 ， 此 种 模式 中 ， 用 户 需 要 为 生产 群集 提供 

整个 组 件 堆栈 ， 包 括 从 底层 计算 、 网 络 和 存储 资源 到 镜像 仓库 等 的 安 
装 、 配 置 和 管理 。 当 然 ， 在 公共 云 环 境 中 ， 一 些 资 源 ( 如 虚拟 机 和 块 存 
储 设备 ) 则 由 Iaas 服 务 商 管理 。 


在 操作 系统 、 和 存储 后 端 和 二 加 网 络 方面 需要 高 度 目 定 义 的 组 织 遂 向 
会 选择 自 定 义 或 日 托管 部 署 ， 毕竟 此 方法 还 提供 了 一 些 其 他 部 著 模 式 中 
可 能 无 法 提供 的 局 级 功能 。 上 自 定 义 部 署 是 最 廉价 的 选择 ， 因 为 客户 只 需 
要 投资 基础 架构 ， 用 到 的 几乎 所 有 的 工具 都 是 开源 的 ， 都 可 以 从 社区 免 
费 获 取 ， 但 是 组 织 必须 考虑 维护 基础 设施 所 涉及 的 人 员 和 支持 成 本 。 


















































而 那些 希望 在 数据 中 心 或 公有 云 环 境 中 运行 Kubernetes 而 无 须 安 装 
或 维护 集群 的 用 户 可 选择 托管 的 Kubernetes 集 群 产 品 ， 提 供 托 管 
Kubernetes 服 务 的 供应 商 则 向 用 户 收 取 集 群 的 管理 和 维护 费用 ， 为 此 用 
户 将 不 得 不 花费 核心 基础 设施 以 及 订购 获得 许可 费用 。 托 管 的 
Kubernetes 平 台 提 供 了 两 全 其 美的 功能 : 基础 设施 的 选择 与 免 维 护 集群 
的 结合 。 不 有 具备 安装 、 配 置 和 管理 大 规模 部 署 所 需 技能 的 组 织 可 以 选择 
台 ， 如 图 13-8 所 示 的 带 有 独立 边框 的 组 件 部 分 将 由 
服务 商 负责 。 
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图 13-8 托管 的 Kubernetes 集 群 环境 


由 于 平台 供应 商 可 以 远程 管理 集群 ， 因 此 用 户 可 以 专注 于 应 用 程序 
的 开发 ， 而 不 是 维护 容器 基础 架构 。 不 过 ， 与 自 托 管 部 署 相 比 ， 托 管 式 
Kubernetes 产 品 更 昂贵 ， 毕 竟 组 织 将 不 得 不 考虑 基础 架构 成 本 以 及 集群 
管理 成 本 ， 好 在 管理 Kubernetes 平 台 的 定期 升级 、 修 补 、 安 全 和 监控 服 
务 的 优势 可 以 在 长 期 预算 范围 内 抵消 一 部 分 成 本 。 此 类 的 常见 解决 方案 
有 IBM Cloud Private、Platform9 和 Tectonic 等 。 


另外 ， 早 期 的 PaaS 实 现 通 常 是 基于 隔离 应 用 程序 上 下 文 的 专 有 技 
术 ， 而 当 Docker 成 为 开源 集装箱 化 搁 术 时 ，PaaS 服 务 商 借助 于 容器 取代 
了 专 有 的 执行 环境 。 如 今 ， 大 多 数 的 Paas 产 品 都 在 容器 上 进行 构建 。 虽 
然 打 包 成 为 容 右 的 程序 代码 仍然 运行 在 虚拟 机 或 物理 服务 器 上 ， 但 
Kubernetes 已 成 为 管理 容器 的 事实 上 的 编排 引擎 ， 那 些 传 统 的 PaaS 完 全 
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可 以 切换 为 构建 在 Kubernetes 的 基础 上 ， 提 供 端 到 端的 应 用 程序 的 生命 
周期 管理 服务 。 


PaaS 可 以 部 署 在 公有 云 坏 境 中 或 企业 数据 中 心 内 部 ， 很 多 大 型 组 织 
正在 采用 PaaS 来 运行 内 部 应 用 程序 以 及 面向 客户 的 应 用 程序 ， 他 们 希望 
0 而 不 考虑 部 署 目标 是 私有 云 还 是 公共 云 环 

。 基 于 Kubernetes 的 PaaSs 产 品 通 过 一 致 的 工作 流程 和 部 署 模式 癌 企 业 
甚至 ， 在 许多 情况 下 ， 开 发 人 员 甚 至 不 需要 知道 他 们 
的 代码 将 在 Kubernetes 集 群 内 运行 。 这 就 意味 着 ，PaaS 层 抽象 了 
Kubernetes 的 底层 细节 ， 并 且 只 公开 了 开发 人 员 理解 的 API 端 点 。 


事实 上 ， 当 DevOps 工 具 部 署 于 Kubernetes 业 务 流程 之 上 时 ， 它 就 扩 
展 成 了 一 个 容器 类 型 的 PaaS 平 台 。 开 发 人 员 不 必 处 理 打包 容器 的 代码 ， 
因为 平台 包含 将 源 代 人 码 转 换 为 镜像 的 工具 ， 并 且 平 台 会 处 理 无 状态 服务 
和 有 状态 服务 之 间 的 连接 ， 开 发 人 员 也 无 须 了 解 如 何 配 置 服务 发 现 机 制 
来 发 现 内 部 和 外 部 服务 ， 如 图 13-9 所 示 。 不 过 ， 尽 管 PaaS 降 低 了 复杂 
性 ， 但 灵活 性 有 所 欠缺 。 
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图 13-9 ”基于 Kubernetes 的 PaaS 


目 托 管 和 托管 的 Kubernetes 集 群 ， 其 目标 是 管理 员 和 DevOps 团 队 ， 
而 基于 Kubernetes 的 PaaS 则 是 为 开发 人 员 所 设计 的 ， 他 们 可 以 将 源 代码 
直接 应 用 于 平台 上 ， 而 不 是 像 Docker 镜 像 或 Kubernetes Pod 那 样 打包 的 








工件 。 他 们 不 需要 处 理 平 台 相 关 的 任何 操作 ， 而 仅 需 要 关注 代码 和 应 用 
程序 生命 周期 。Kubernetes 已 经 成 为 现 如 今 Paas 平 台 实 践 的 基础 ，Red 
Hat OpenShift 和 Mesosphere DC/OS 是 著名 的 其 于 Kubernetes 的 PaaS 广 

器 

口 口 





最 后 ， 随 者 Kubernetes 的 成 熟 ， 其 用 例 开 始 超越 普通 的 容器 编排 服 
务 而 逐渐 被 用 于 多 种 小 众 场景 中 ， 这 包括 边缘 计算 〈Edge 
Computing) 、 机 器 学 习 、 无 服务 计算 (Serverless Computing ) 和 数据 
流 分 析 (Stream Analytics) 等 ， 尤 其 值得 一 提 的 是 新 近 兴 起 的 无 服务 计 
算 。 目 前 ， 无 服务 计算 与 虚拟 机 和 容器 一 起 已 成 为 公有 云 提供 商 提 供 的 
基本 计算 服务 。 不 过 ， 与 其 他 计算 服务 不 同 的 是 ， 无 服务 计算 基于 事件 
驱动 ， 开 发 人 员 以 功能 的 形式 将 代码 片段 上 传 到 无 服务 器 平台 后 ， 它 们 
只 会 在 外 部 事件 触发 时 执行 ， 而 非 一 直 以 后 台 进 程 处 于 守护 运行 状态 。 
AWS Lambda、Azure 函 数 和 Google Cloud Functions 是 公有 云 中 一 些 流行 
的 无 服务 器 计算 选择 。Docker 可 用 于 无 服务 器 计算 ， 于 是 Kubernetes 成 
为 在 运行 时 管理 这 些 Docker 容 器 的 首选 项 。Apache OpenWhisk、 
Fission、Kubeless、nuclio 和 OpenFaaSs 是 基于 Kubernetes 的 部 署 Serverless 
的 项 目 。 

















13.5” 容 右 时 代 的 DevOps 概 述 


DevOps 的 理论 和 实践 起 源 于 2009 年 前 后 ， 但 最 初 应 用 的 大 趋势 不 
温 不 火 ， 直 到 容器 技术 出 现 并 迅速 流行 开 来 之 后 ，DevOps 才 日 渐 红火 
起 来 。 究 其 原因 ， 其 中 的 一 个 可 能 性 便 是 ， 容 器 是 一 个 催化剂 ， 它 让 
DevOps 文 化 的 落地 变 得 更 加 易于 实现 。 


应 用 程序 的 设计 架构 从 单 体 架构 及 展 到 分 层 架 构 之 后 ， 各 种 分 布 式 
协作 的 组 件 通 第 会 由 不 同 的 开发 团队 来 维护 和 交付 ， 这 些 应 用 组 件 可 能 
使 用 了 不 同 的 编程 语言 ， 依 赖 于 不 同 的 开发 库 环 境 及 外 部 协作 关系 ， 这 
种 系统 架构 部 晋 和 维护 的 复杂 度 为 运 维 工作 市 来 了 极 大 的 挑战 ， 这 一 点 
通过 13.5 贡 中 描述 的 DevOps 各 环节 层出不穷 的 可 用 工具 也 可 见 一 斑 。 如 
今 ， 应 用 程序 的 分 层 架 构 进 一 步 发 展 至 微服 务 架 构 ， 开 发 人 员 获 得 便利 
的 同时 ， 运 维 工作 的 挑战 性 却 有 痢 进 一 步 上 升 之 势 。 


容器 技术 的 出 现 使 得 运 维 工作 复 共 上 度 不 断 上 升 的 难题 迅速 得 以 冰 消 
瓦解 ，DevOps 在 技术 层面 的 落地 不 再 是 眼花 综 乱 的 局 面 ， 它 们 被 统一 
在 容器 镜像 制作 、 分 发 和 部 普 的 纬度 上 。 通 过 使 用 Dockerfile 构 建 容 融 
镜像 ， 应 用 的 配置 和 部 署 工作 被 提前 到 了 编译 时 进行 ， 这 一 点 改变 了 之 
前 制作 好 应 用 发 布 于 不 同 的 环境 中 之 后 再 去 手动 调整 环境 变量 的 传统 做 
0 




















13.5.1 ”容器 : DevOps 协 作 的 基础 


容 髓 技术 解决 了 不 同系 统 环境 上 应 用 程序 的 配置 和 维护 的 复杂 上 度 难 
题 ， 从 而 使 得 开发 人 员 和 IT 运 维 人 员 能 够 更 紧密 和 更 局 效 地 协作 ， 为 
DevOps 的 快速 落地 提供 了 一 个 极 具 效用 的 突破 口 。 有 了 容 促 ， 传 统 
DevOps 实 践 中 不 得 不 为 各 种 环境 中 应 用 程序 的 构建 和 释 出 进行 复杂 配 
置 的 局 面 ， 被 容器 扩 术 极 大 地 人 简化 了 。 


借助 Docker 容 器 ， 开 发 人 员 可 以 做 到 将 精力 集中 于 容器 中 内 容 的 构 
建 《应 用 程序 和 服务 ， 以 及 它们 所 依赖 的 框 桨 和 组 件 ) 以 及 如 何 将 容器 
和 服务 协同 在 一 起 工作 之 上 。 当 然 ， 容 器 协调 的 编排 机 制 有 赖 于 编排 工 
其 的 介入 。 相 对 应 地 ，IT 运 维和 人 员 则 可 以 将 主要 精力 集中 于 生产 环境 管 
理 方 面 ， 例 如 基础 架构 、 系 统 扩 缩 容 、 监 控 ， 以 及 将 应 用 程序 正确 交付 
到 终端 用 户 等 ， 他 们 根本 无 须 关 心 容 需 内容 本 号 。 


如 图 13-10 所 示 ， 开 发 人 员 负 责 开 发 编写 容器 中 运行 的 应 用 程序 ， 
他 们 通过 Dockerfile 来 定义 应 用 程序 所 依赖 的 系统 环境 ， 以 及 将 代码 构 
建 到 容器 镜像 中 的 步 又， 并 借助 于 编排 工具 的 编排 机 制定 义 容 器 的 协同 
方式 。 遵 循 业务 环境 需求 ， 将 制作 好 的 Docker 配 置 文件 推送 至 项 目的 代 
码 仓库 中 〈 如 Git 仓 库 ) 即 可 进入 后 续 的 步骤 。 
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图 13-10 ”容器 模型 中 的 DevOps 来源: microsoft.com ) 
接 下 来 ， 在 DevOps 环 节 持 续集 成 〈CI) 流水 线 从 Git 仓 库 中 获取 到 











的 Dockerfile， 结 合 从 镜像 仓库 中 拿 到 基础 镜像 自动 构建 自 定 义 的 容器 
2 
中 个 F 。 


随后 ， 由 CD“《〈 持 续 交 付 和 技术 部 著 ) 流水线 自动 完成 基础 设施 构 
建 、 环 境 设 定 、 容 器 部 署 和 监控 等 工作 ， 并 将 系统 状态 数据 不 断 地 反馈 
至 开发 团队 。 对 于 此 环节 来 说 ， 不 同 的 团队 的 不 同 项 目的 自动 化 程度 可 
能 会 有 所 不 同 ， 有 的 甚至 还 可 能 会 由 运 维 团队 手工 完成 。 


由 此 可 见 ， 开 发 和 运 维 两 个 团队 在 容器 平台 的 辅助 下 得 以 完成 协 
司 ， 从 而 大 大 缩短 了 软件 开发 的 生命 周期 。 开 发 人 员 人 负 员 维护 容 絮 的 内 
而 运 维 人 员 则 负责 在 编排 系统 的 辅助 下 将 镜像 运行 为 一 个 个 的 容 

















当 并 可 


13.5.2 ” 泛 型 霄 到 闯 容 需 应 用 程序 生命 周期 工作 沉 


图 13-11 提 供 了 更 详细 的 Docker 应 用 程序 生命 周期 的 工作 流 ， 其 着 
重 描 述 了 DevOps 的 活动 和 资产 。 


DevOps 流 程 始 于 开发 人 员 ， 他 们 在 自 有 的 内 部 循环 中 编写 并 调试 
程序 代码 ， 而 后 将 “稳定 ”状态 的 代码 推送 至 代码 仓库 (如 Git〉 中。 提交 
完成 后 ， 代 码 仓库 将 触发 CI 和 工作 流 的 其 余部 分 。 


DevOps 工 作 流 不 仅仅 是 一 个 工具 集合 ， 它 更 是 一 种 软件 开发 演进 
而 来 的 文化 ， 它 是 使 得 软件 开 及 更 敏捷 及 可 预 调 的 人 员 、 流 程 和 相应 的 
工具 的 集成 。 于 是 ， 采 用 了 容器 化 工作 流 的 组 织 就 需要 基于 容器 工作 流 
来 重 构 他 们 的 组 织 及 其 工作 机 制 。 实 践 DevOps， 以 目 动 化 取代 手工 区 
动 从 而 大 大 提升 效率 并 降低 出 错 的 可 能 性 ， 从 而 帮助 组 织 或 企业 内 容 更 
高 效 地 协作 以 获得 更 好 的 竞争 优势 。 男 外 ， 组 织 还 可 以 结合 云 计算 按 需 
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图 13-11 泛 型 端 到 端 容 器 生命 周期 工作 流 〈 来 源 : microsoft.com) 


13.5.3 ”基于 Kubernetes 的 DevOps 


在 DevOps 工 作 流 中 ，Kubernetes 作 为 运行 时 环境 中 的 编排 工具 ， 用 
于 容器 的 编排 运行 。 例 如 ， 如 图 13-12 所 示 的 DevOps 工 具 链 中 所 展示 的 
DevOps 工 作 流 包括 如 下 内 容 。 


1) 开发 人 员 编 写 应 用 代码 推送 至 Git 上 的 代码 仓库 ， 而 后 经 CI 工具 
链 构 建 、 测 试 后 释 出 。 

2) 开发 人 员 编写 Dockerfile 推 送 至 Git 上 的 项 目 仓 库 中 ， 而 后 基于 基 
础 镜像 和 释 出 的 应 用 程序 构建 Docker 镜 像 ， 并 推送 至 Docker 仓 库 中 。 


3) 开发 人 员 编 写 Kubernetes 清 单 (manifest) 或 helm charts， 而 后 由 
kube applier 应 用 《创建 或 升级 )》 至 Kubernetes 集 群 加 以 运行 
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图 13-12 ”基于 Kubernetes 的 人 流 


kube-applier 是 一 种 服务 ， 在 集群 中 作为 Pod 运 行 ， 并 监视 Git 仓 库 ， 
通过 将 声明 性 配置 文件 从 Git 存 储 库 应 用 到 Kubernetes 和 集群， 实现 持续 章 
署 资 源 对 象 。 图 13-12 显 示 的 工作 流 中 ，Jenkins 是 整个 CUCD 流 水 线 的 
Hub， 它 经 由 Git WebHook 触 用 控制 者 CI、 镜像 构建 、Kubernetes Pod 创 
建 和 编排 等 一 应 操作 。 


此 种 场景 中 ，Jenkins 承 担 了 太 多 的 工作 ，CI、 镜 像 构建 、 基 础 环 
境 、 应 用 部 署 均 由 其 负责 实施 ， 每 当 有 团队 需要 做 一 个 新 的 部 署 流水 线 
时 ， 就 会 根据 具体 需求 进行 微调 ， 必 要 时 还 得 重 写 所 有 的 脚本 ， 效 率 略 
低 。 对 于 有 研发 实力 的 组 织 ， 可 以 把 关键 的 工作 做 成 单独 的 系统 ， 例 
a $0 60 而 是 分 别 做 成 独立 


另外 ，DevOps 的 流程 中 需要 的 各 种 工具 链 几 乎 都 可 以 托管 于 
Kubernetes 平 台 之 上 和 运行， 包括 Jenkins。 此 时 ， 再 加 上 Kubernetes 平 台 文 
持 的 调度 、 健 康 检 查 、 日 志 、 监 控 、 安 全 、 应 用 服务 、 弹 性 扩 缩 容 和 服 
务 发 现 等 功能 ， 就 是 一 个 完整 的 容器 云 平 台 。 不 过 ， 有 些 开源 项 目 本 续 
己 经 直接 集成 了 这 些 功 能 ， 如 OpenShift 和 Tectonic 等 。 














13.6 本章 小 结 


本 章 主 要 讲解 了 自 定义 资源 类 型 CRD、 自 定义 资源 对 象 、 自 定义 控 
制 器 、 自 定义 API Server 及 API 聚 合 等 Kubernetes API 的 扩展 方式 ， 给 出 
了 Kubernetes 集 群 高 可 用 架构 中 控制 平面 的 实现 机 制 ， 并 说 明了 生产 环 
境 中 Kubernetes 集 群 的 第 见 部 署 方式 。 





第 14 半 ”资源 指标 及 HPA 控 制 嚣 


资源 监控 系统 是 容 右 编排 系统 必 不 可 少 的 组 件 ， 它 为 用 户 提 供 了 快 
速 了 解 系统 资源 分 配 和 利用 状态 的 有 效 途 笃 ， 同 时 也 是 系统 编排 赖 以 实 
现 的 基础 要 件 。 在 新 一 代 监 控 架 构 体 系 中 ，Kubernetes 将 资源 指标 的 规 
范 及 其 实现 分 离开 来 ， 为 用 户 提 供 了 极 大 的 扩展 空间 。 本 和 章 将 主要 说 明 
如 何 为 Kubernetes 集 群 提 供 资源 监控 机 制 并 利用 资源 指标 。 





14.1 资源 监控 及 资源 指标 


监控 应 用 程序 的 当前 状态 是 帮助 预测 问题 并 发 现 生产 环境 中 资源 瓶 
颈 的 最 有 效 方法 之 一 ， 但 它 也 是 目前 几乎 所 有 软件 开发 组 织 面临 的 最 大 
挑战 之 一 ， 然 而 ， 微 服务 的 日 荔 普 及 使 得 日 志 记 录 和 监控 变 得 更 加 复 
杂 ， 因 为 大 量 正 在 通信 的 应 用 程序 本 质 上 是 分 布 式 和 多 样 化 的 ， 茶 个 单 
点 故障 甚 全 可 以 中 断 整个 系统 ， 但 识别 它 却 变 得 越 来 越 困 难 。 


当然 ， 监 控 只 是 微服 务 体系 中 众多 挑战 中 的 一 个 ， 此 外 ， 处 理 可 用 
性 、 性 能 和 应 用 部 署 等 必然 地 推动 了 团队 创建 或 使 用 编排 工具 来 处 理 所 
有 服务 和 主机 ， 这 也 是 Kubernetes 这 一 类 的 编排 系统 迅速 流行 的 原因 之 
一 ， 因 为 它 能 够 处 理 多 人 台 计算 机 中 的 容器 ， 并 消除 了 处 理 分 布 式 处 理 的 
一 来 问题 又 转 为 了 如 何 有 效 地 监控 Kubernetes 系 统 并 输 
站 标 数据 。 


众所周知 ， 基 于 诸如 CPU 和 内 存 使 用 等 指标 自动 缩放 工作 负载 规模 
的 能 力 是 Kubernetes 最 强大 的 功能 之 一 。 当 然 ， 要 启用 此 功能 ， 首 先 需 
要 一 种 收集 和 存储 这 些 指 标的 方法 ， 曾 经 ， 这 必然 是 指 Heapster。 不 
过 ， 传 统 的 基于 Heapster 收 集 的 数据 指标 进行 工作 负载 缩放 的 方法 仅 文 
持 CPU 一 项 指标 ， 要 扩展 为 文 持 多 种 指标 可 能 有 着 不 小 的 厂 烦 ， 并 且 来 
和 目 于 项 目的 各 种 贡献 者 的 文 持 也 不 一 致 ， 因 此 它 不 久 后 可 能 会 被 淘汰 。 
科 运 的 是 ，Kubernetes 新 的 指标 API 实 现 了 一 种 更 为 一 臻 和 高 效 的 供给 指 
的 方式 ， 这 为 以 自 定义 指标 为 基础 的 自动 缩放 目标 提供 了 可 行 的 
实 霓 。 


























14.1.1 资源 监控 及 Heapster 








Kubernetes 有 多 个 数据 指标 需要 采集 相关 的 数据 ， 而 这 些 指标 大 体 
上 可 以 分 为 两 个 主要 组 成 部 分 : 监控 集群 本 身 和 监控 Pod 对 象 。 在 集群 
监控 层面 ， 目 标 是 监控 整个 Kubernetes 集 群 的 健康 状况 ， 包 括 集群 中 的 
所 有 工作 节点 是 个 运行 正常 、 系 统 资源 容量 大 小 、 每 个 工作 节点 上 运行 
的 容 咒 化 应 用 的 数量 以 及 整个 集群 的 资源 利用 率 等 ， 它 们 通 浓 可 分 为 如 
下 一 些 可 衡量 的 指标 。 


1) 市 反 资 源 状 态 : 这 个 领域 的 众多 指标 都 与 资源 利用 状况 有 关 ， 
主要 有 网 络 带宽 、 磁 盘 空 间 、CPU 和 内 存 的 利用 率 ; 基于 这 些 度量 指 
标 ， 管 理 员 能 够 评估 集群 规模 的 合理 性 。 


2) 节点 数量 : 当今， 众多 公有 云 服务 商 均 以 客户 使 用 实例 数量 计 
算 费 用 ， 于 是 即时 了 解 到 集群 中 的 可 用 节点 数量 可 以 为 用 户 计算 所 需要 
文 付 的 费用 提供 参考 指标 。 


3) 运行 的 Pod 对 象 : 正在 运行 的 Pod 对 象 数 量 能 够 用 于 评估 可 用 节 
Bd 以 及 在 节点 发 生 故 障 时 它们 是 否 能 够 承接 整个 工作 
负载 。 


男 一 方面 ，Pod 资 源 对 象 的 监控 需求 大 体 上 可 以 分 为 三 类 : 
Kubernetes 指 标 、 容 器 指标 和 应 用 程序 指标 。 


1) Kubernetes 指 标 : 用 于 监视 特定 应 用 程序 相关 的 Pod 对 象 的 部 署 
过 程 、 当 前 副本 数量 、 期 望 的 副本 数量 、 部 署 过 程 进展 状态 、 健 康 状 态 
监测 及 网 络 服务 器 的 可 用 性 等 ， 这 些 指标 数据 需要 经 由 Kubernetes 系 统 
接口 获取 。 

2) 容 右 指标 : 容器 的 资源 需求 、 资 源 限 制 以 及 CPU、 内 存 、 磁 盘 
空间 、 网 络 市 宽 等 资源 的 实际 占用 状况 等 。 


3) 应 用 程序 指标 : 应 用 程序 自 映 内 建 的 指标 ， 通 常 与 其 所 处 理 的 
业务 规则 相关 ， 例 如 ， 关 系 型 数据 库 应 用 程序 可 能 会 内 建 用 于 其 露 索 引 
状态 有 关 的 指标 ， 以 及 表 和 关系 的 统计 信息 等 。 





























监控 集群 所 有 节点 的 一 种 方法 是 通过 DaemonSet 控 制 器 在 各 节点 部 
署 一 个 用 于 监控 指标 数据 采集 功能 的 Pod 对 象 运行 监控 代理 程序 
(Cagent) ， 并 在 集群 上 部 署 一 个 收集 各 节点 上 由 代理 程序 采集 的 监控 数 
据 的 中 心 监控 系统 ， 统 一 进行 数据 的 采集 、 存 储 和 展示 。 这 种 部 署 方 式 
给 了 管理 员 很 大 的 自主 空间 ， 但 也 必定 难以 形成 统一 之 势 。 


于 是 ，Kubernetes 系 统 特 地 于 kubelet 程 序 中 集成 相关 的 工具 程序 
cAdvisor， 用 于 对 节点 上 的 资源 及 容器 进行 实时 监控 及 指标 数据 采集 ， 
文 持 的 相关 指标 包括 CPU、 上 入 存 使 用 情况 、 网 络 吞 吐 量 及 文件 系统 使 用 
情况 等 ， 并 可 通过 TCP 的 4194 端 口 提 供 一 个 web UI (kubeadm 的 默认 部 
署 未 启用 此 功能 ) 。 需 要 快速 了 解 茶 特定 节点 上 的 CAdvisor 运 行 是 否 正 
常 ， 以 及 了 解 单 节点 的 资源 利用 状态 时 ， 可 直接 访问 cAdvisor Web UL 
URL 是 http:/<Node_IP>>:4194/ ， 其 默认 的 界面 如 图 14-1 所 示 。 
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图 14-1 cAdvisor 图 形 面板 


cAdvisor 的 问题 同样 在 于 其 仅 能 收集 单个 布点 及 其 相关 Pod 资 源 的 
相关 指标 数据 。 事 实 上 ， 将 各 工作 节 扣 采集 的 指标 数据 予以 汇集 并 通过 
一 个 统一 接口 癌 外 暴露 不 仅 能 为 用 户 带 去 便捷 ， 而 且 也 是 Kubernetes 系 








统 某 些 组 件 所 依赖 的 底层 功能 ， 这 些 组 件 包 括 kubectl top 命 令 、 
Horizontal Pod Autoscalers 〈 即 HPA) 资源 以 及 Dashboard 的 某 些 功能 
A 





~]$ kubectl1 top nodes 
Error from server (NotFound): the server could not find the requested resource 
(get services http:heapster:) 





Heapster 是 这 类 项 目的 一 个 着 名 实现 ， 用 于 为 集群 提供 指标 API 及 其 
实现 ， 并 进行 系统 监控 ， 而 且 它 曾 与 ClusterDNS、Ingress 和 Dashboard 一 
起 并 称 为 Kubernetes 的 四 大 核心 附件 ， 其 组 件 结构 如 图 14-2 所 示 。 





Storage Backend 





图 14-2 ”Heapster 系 统 数据 流向 


Heapster 是 集群 级 别 的 监视 和 事件 数据 聚合 工具 ， 它 原生 支持 并 且 
适用 于 所 有 方式 构建 的 Kubernetes 集 群 系统 。Heapster 本 喘 可 作为 集群 中 
的 一 个 Pod 对 象 运行 ， 它 通过 发 现 集群 中 的 所 有 节点 实现 从 每 个 节点 
kubelet 内 建 的 cAdvisor 获 取 性 能 和 指标 数据 ， 并 通过 标签 将 Pod 对 象 及 其 
相关 的 监控 数据 进行 分 级 、 聚 合 后 推送 到 可 配置 的 后 几 存 储 系 统 进行 存 
储 和 可 视 化 。 


功 能 完备 的 Heapster 监 控 系 统 流行 的 解决 方案 是 由 InfluxDB 作 为 存 
储 后 端 ，Grafana 为 可 视 化 接口 ， 而 Heapster 从 各 节点 的 cAdvisor 采 集 数 
据 并 存储 于 InfluxDB 中 ， 由 Grafana 进 行 展示 。 托 管 于 Kubernetes 集 群 中 
的 InfluxDB、Grafana 和 Heapster 运 行 为 常规 的 Pod 资 源 对 象 ， 它 们 彼此 之 
间 通 过 环境 变量 及 服务 发 现 功 能 自动 协同 。 男 外 ， 它 还 文 持 其 他 多 种 后 


端 ， 如 OpenTSDB、Elasticsearch、Log、Monasca、Kafka、Riemann 和 
Hawkular-Metrics 等 ， 可 按 需 灵活 组 合 出 多 种 不 同 的 监控 解决 方案 。 


然而 ，Heapster 文 持 的 每 个 存储 后 端的 代码 都 直接 驻 留 在 其 代码 仓 
库 中 成 为 核心 代码 库 的 一 部 分 ， 结 果 是 必然 会 被 烂 尾 的 驻 留 代码 所 拖 
办， 这 甚至 是 成 为 了 用 户 使 用 Heapster 最 和 常见 的 挫败 原因 。 更 重要 的 
是 ， 即 使 Heapster 没 有 将 Prometheus 作 为 数据 接收 器 ， 却 又 暴露 了 
Prometheus 格 式 的 指标 ， 这 通 利 会 引起 不 小 的 混 消 和 麻烦 。 


换 句 话说 ，Heapster 既 为 那些 依赖 于 指标 数据 的 系统 组 件 提 供 了 指 
标 API〈 非 标准 格式 的 一 等 类 别 Kubernetes API) ， 同 时 又 提供 了 指标 
API 接 口 背 后 的 实现 方式 ， 即 收集 和 存储 指标 数据 以 啊 应 对 API 的 请 
求 。 这 种 以 耦合 度 较 高 的 方式 实现 核心 系统 组 件 依赖 到 的 功能 部 件 的 做 
法 对 系统 的 变迁 引入 了 不 少 的 不 确定 性 和 隐患 。 


另外 ，Heapster 假 设 数据 存储 是 一 个 原始 的 时 间 序 列 数 据 库 ， 这 些 
数据 库 都 有 着 一 个 可 直接 写 入 路 径 。 这 使 得 它 与 Prometheus 系 统 基本 上 
不 相 兼 容 ， 因 为 Prometheus 工 作为 拉 取 式 模型 。 然 而 ，Kubernetes 生 态 
系统 的 整体 组 件 几乎 原生 支持 Prometheus 系 统 ， 于 是 ，Heapster 的 这 部 
分 功能 逐渐 被 其 所 取代 。 


为 了 避免 重 蹈 Heapster 的 窗 办 ， 资 源 指标 API (resource metrics 
api) 和 自 定 义 指标 API (custom metrics api) 被 有 意 地 创建 为 纯粹 的 API 
定义 而 非 具 体 的 实现 ， 它 们 作为 聚合 的 API 安 装 到 Kubernetes 集 群 中 ， 从 
而 允许 在 API 保 持 不 变 的 情况 下 切换 其 具体 的 实现 方案 ， 这 一 点 极 大 地 
降低 了 二 者 的 耦合 级 别 。 最 终 ，Heapster 用 于 提供 核心 指标 API 的 功能 
被 聚合 方式 的 指标 API 服 务 器 metrics-server 所 取代 。 











14.1.2 ”新 一 代 监 控 架 构 


Kubernetes 如 此 强大 的 原因 之 一 便 是 其 灵活 的 可 扩展 性 ， 其 中 表现 
得 尤为 抢眼 的 是 ， 它 通过 API 聚 合 器 为 开发 人 员 提 供 了 轻松 扩展 API 资 
源 的 能 力 ，Kubernetes 在 1.7 版 本 中 引入 的 自 定 义 指标 API (custom 
metrics API) ， 以 及 在 1.8 版 本 中 引入 的 资源 指标 API (resource metrics 
API， 人 简称 为 指标 API) 都 属于 这 种 类 型 的 扩展 。 


资源 指标 API 主 要 供 核 心 系统 组 件 使 用 ， 如 调度 程序 、HPA 

和 “kubectl top” 命 令 等 ， 虽 然 是 以 扩展 方式 实现 API， 但 它 提供 的 是 
kubernetes 系 统 必 备 的 “核心 指标 >， 因此 不 适用 于 与 第 三 方 监 控 系 统 集 
成 ， 如 Prometheus 等 。 男 一 方面 ， 自 定义 指标 API 则 为 用 户 提 供 了 自行 
按 需 扩展 指 标的 接口 ， 它 允 许 用 户 自 定 义 指标 类 型 的 API Server 并 直接 
聚合 进 主 API Server 中 ， 因 此 具有 更 广泛 的 使 用 场景 。 简 和 单 总 结 起 来 就 
是 ， 新 一 代 的 Kubemelss 监 控 系 统 架 构 主要 由 核心 指标 流水 线 和 监控 指 
标 流水 线 协同 组 成 ， 具 体 如 下 。 


(1) 核心 指标 流水 线 


由 kubelet、 资 源 评估 器 、metrics-server 以 及 由 API Server 提 供 的 API 
群 组 (由 APIService 对 象 提供 ) 组 成 ， 如 图 14-3 所 示 ， 它 们 可 用 于 为 
Kubernetes 系 统 提供 核心 指标 ， 从 而 能 够 了 解 并 操作 其 内 部 组 件 和 核心 
程序 。 和 截至 目前 ， 相 关 的 指标 主要 包括 CPU 宗 计 使 用 、 内 存 即 时 使 用 
率 、Pod 的 资源 占用 率 及 容器 的 破 盘 占用 率 等 几 个 。 所 用 到 的 度量 标准 
核心 系统 组 件 包括 调度 逻辑 (基于 指 慰 数 据 的 调度 程序 和 应 用 规模 的 水 
平 缩放 ) ， 以 及 部 分 UI 组 件 〈 如 kubectl top 命 令 和 Dashboard) 等 。 


(2) 监控 指标 流水 线 


监控 指标 流水 线 用 于 从 系统 收集 各 种 指标 数据 并 提供 给 终端 用 户 、 
存储 系统 以 及 HPA 控 制 器 等 使 用 ， 它 收集 的 数据 指标 也 称 为 非 核心 指 
标 ， 但 它们 通常 也 包含 核心 指标 (未 必 是 Kubernetes 可 以 理解 的 格式 ) 
以 及 其 他 指标 。 上 自 定 义 指标 API 人 允许 用 户 扩 展 任意 数量 的 特定 于 应 用 程 
序 的 指标 ， 例 如 ， 其 指标 可 能 包括 队列 长 度 和 每 秒 入 口 请 求 数 等 。 
Kubernetes 系 统 本 身 不 会 提供 此 类 组 件 ， 也 不 会 对 这 些 指 标 提供 相关 的 
解释 ， 它 有 赖 于 用 户 按 需 选择 使 用 的 第 三 方 解 决 方案 。 目 定义 指标 API 

















系统 组 件 如 图 14-4 所 示 。 
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图 14-3 ”资源 指标 API 系 统 组 件 
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图 14-4” 自 定义 指标 API 系 统 组 件 


一 个 能 同时 使 用 资源 指标 API 和 自 定义 指标 API 的 组 件 是 第 二 版 的 
HorizontalPod-Autoscaler 控 制 器 (HPAv2) ， 它 实现 了 基于 观察 到 的 指 





标 上 自动 缩放 Deployment 或 ReplicaSet 类 型 控制 器 管控 下 的 Pod 副 本 数量 。 
HPA 的 第 一 个 版 本 只 能 根据 观察 到 的 CPU 利用 率 进 行 扩展 ， 尽 管 在 某 些 
情况 下 很 有 用 ， 但 CPU 并 不 总 是 最 适合 自动 调整 应 用 程序 的 度量 指标 。 


从 根本 上 来 讲 ， 资 源 指标 API 和 上 自 定义 指标 API 都 仅 是 API 的 定义 和 
规范 ， 它 们 上 自 映 都 并 非 具 体 的 API 实 现 。 目 前 ， 资 源 指 标 API 的 实现 较 
主流 是 的 metrics-server， 而 自 定义 指标 API 则 以 建构 在 监控 系统 
Prometheus 之 上 的 k8s-prometheus-adapter 最 广 为 接受 。 事 实 上 ， 
Prometheus 也 是 CNCF 旗 下 的 项 目 之 一 ， 并 且 得 到 了 Kubernetes 系 统 上 众 
多 组 件 的 原生 文 持 。 

















14.2 ”资源 指标 及 其 应 用 


如 前 所 述 ， 自 Kubernetes 1.8 版 本 起 ， 诸 如 容器 的 CPU 和 内 存 资 源 占 
用 状况 一 类 的 资源 利用 率 指标 可 由 客户 端 通过 指标 API 直 接 调用 ， 这 些 
客户 端 包 括 但 不 限于 终端 用 户 、kubect top 命令 和 HPA (v2) 等 。 另 
外 ， 尽 管 通 过 指标 API 能 够 查询 某 节 点 或 Pod 的 当前 资源 占用 情况 ， 但 
API 本 身 并 不 存储 任何 指标 数据 ， 因 此 ， 它 仪 提供 资源 占用 率 的 实时 监 
测 数 据 而 无 法 提供 过 去 指定 时 刻 的 指标 监测 记录 结果 。 














14.2.1 部 署 metrics-server 


事实 上 ， 资 源 指标 API 与 系统 的 其 他 API 并 无 特别 不 同 之 外 ， 它 通 
过 API Server 的 UREL 路 径 /apis/metricsk8s.io/ 进 行 存 取 ， 并 提供 同样 级 别 
的 安全 性 、 稳 定性 及 可 靠 性 保证 。 不 过 ， 只 有 在 Kubernetes 集 群 中 部 署 
Metrics Server( 指 标 服务 器 〉 应 用 之 后 ， 指 标 API 方 才 可 用 。 资 源 指标 
API 架 构 简 图 如 图 14-5 所 示 。 


Metrics Server 是 集群 级 别 的 资源 利用 率 数 据 的 聚合 器 
Caggregator) ， 它 的 创建 于 不 少 方面 都 受到 了 Heapster 的 启发 ， 且 于 功 
能 和 特性 上 完全 可 被 视 作 一 个 仅 服务 于 指标 数据 的 简化 版 的 Heapster。 
Metrics Server 通 过 Kubernetes 肾 合 嚣 (kube-aggregator) 注册 到 主 API 
Server 之 上 ， 而 后 基于 kubelet 的 Summary API 收 集 每 个 节点 上 的 指标 数 
据 ， 并 将 它们 存储 于 内 存 中 然后 以 指标 API 格 式 提 供 ， 如 图 14-6 所 示 。 
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图 14-5 “资源 指标 API 架 构 简 图 
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图 14-6 “聚合 metrics-server 于 主 API Server 上 


Metrics Server 基 于 内 存 存 储 ， 重 启 后 数据 将 全 部 丢失 ， 而 且 它 仅 能 
留存 最 近 收 集 到 的 指标 数据 ， 因 此 ， 如 果 用 户 期 望 访问 历史 数据 ， 就 不 
和 (如 Prometheus 等 ) ， 或 者 自行 开发 以 实 
现 其 功能 。 


Metrics Server 是 Kubernetes 多 个 核心 组 件 的 基础 依赖 ， 因 此 ， 它 应 
该 默认 部 署 运行 于 集群 中 。 一 般 说 来 ，Metrics Server 在 每 个 集群 中 仅 会 
运行 一 个 实例 ， 启 动 时 ， 它 将 自动 初始 化 与 各 节点 的 连接 ， 因 此 出 于 安 
全 方面 的 考虑 ， 它 需要 运行 于 普通 节点 而 非 Master 主 机 之 上 。 直 接 使 用 
项 目 本 身 提供 的 资源 配置 清单 即 能 轻松 完成 metrics-server 的 部 堵 ， 下 面 
就 来 分 步 说 明 其 实施 步 又 。 


(1) 克隆 项 目 代 码 的 仓库 至 本 地 目录 以 获得 其 资源 配置 清单 











~]$git clone https://github.com/kubernetes-incubator/metrics-server.git 





注意 ， 截 至 有 目前，metrics-server 程 序 默 认 会 从 kubelet 的 基于 HTTP 通 
信 的 10255 端 口 获取 指标 数据 ， 但 出 于 安全 通信 的 目的 ，Kubernetes 1.11 
版 本 的 kubeadm 在 初始 化 集群 时 会 关 掉 kubelet 基 于 HTTP 的 10255 端 口 ， 
从 而 导致 其 部 署 完 成 后 无 法 正常 获取 数据 。 另 外 ， 人 代码 仓库 中 的 部 署 清 
单 文 件 deplow1.8+/metrics-server-deployment.yaml 中 并 未 明确 为 主 程 
序 /metrics-server 传 递 参 数 指定 指标 数据 的 获取 接口 ， 它 通常 应 该 是 








kubernetes.summary_api。 因 此 ， 在 启动 部 得 操作 之 前 ， 需 要 修改 此 清单 
文件 ， 下 面 在 metrics-server 容 器 配置 段 中 添加 如 下 内 容 : 





command: 

- /metrics-server 

- --Source=kubernetes.summary_api:https://kubernetes.defaultkubeletHttps=true 
&kubeletPort=10250&insecure=true 





Metrics Server 项 目 处 于 非常 活跃 的 维护 状态 ， 其 相应 的 代码 仓库 或 
许 在 读者 读 到 此 书 时 便 已 完成 了 修正 ， 因 此 建议 进行 metrics-server 部 署 
时 先 不 做 修改 ， 待 部 署 后 观测 到 连接 kubelet 错 误 一 类 的 信息 时 再 予以 手 
动 更 正 。 


(2) 基于 资源 配置 清单 完成 相应 资源 的 创建 





~]$ kubect1 apply -f metrics-server/deploy/1.8+/ 





各 部 蜀 清 单 会 于 kube-system 名 称 空间 中 创建 出 多 个 类 型 的 资源 对 
象 ， 包 括 RBAC 相 关 的 rolebinding、clusterrole 和 clusterrolebinding 对 象 ， 
以 及 serviceaccount 对 象 用 于 在 启用 了 RBAC 授 权 插 件 的 集群 上 完成 对 
metrics-server 开 放 资源 访问 的 许可 。 另 外 ， 它 还 会 通过 一 个 APIService 
对 象 创 建 Metrics API 相 关 的 群 组 从 而 将 metrics-server 提 供 的 API 聚 合 i 
主 API Server 上 。 因 此 ， 接 下 来 要 检验 相应 的 API 群 组 metrics.k8s.io 是 人 否 
出 现在 Kubernetes 集 群 的 API 群 组 列表 中 : 





~]$ kubectl1 api-versions | grep metrics 
metrics.k8s.io/vibetal 





(3) 确认 相关 的 Pod 对 象 运行 正常 
首先 检查 metrics-server 的 Pod 对 象 是 否 处 于 “Running” 状 态 : 





~]$ kubect1 get pods -n kube-system -1] k8s-app=metrics-server 
NAME READY STATUS RESTARTS AGE 
metrics-server-778ddc45b5-hvwdh 1/1 Running 0 7Zm 











而 后 检查 Pod 中 的 容器 其 日 志 信 息 中 是 含 出 现 错误 提示 : 





~]$ kubect1 Jogs metrics-server-778ddc45b5-hvwdh -n kube-system 





(4) 检查 资源 指标 API 的 可 用 性 


“kubectl get--raw” 命 令 可 用 于 基于 资源 URL 路 径 测 试 资源 指标 API 服 
务 的 可 用 状态 ， 例 如 以 下 命令 应 返回 集群 中 所 有 节点 的 资源 使 用 情况 指 
标 列 表 ， 它 能 够 列 出 集群 中 所 有 节点 的 CPU 及 内 存 资源 占用 情况 。 在 使 
用 时 ， 也 可 以 直接 给 定 具 体 的 节点 标识 ， 从 而 仪 列 出 特定 节点 的 相关 信 











~]$ kubect1 get --raw "/apis/metrics.k8s.io/vibetai/nodes" | jq. 


"kind": "NodeMetricsList", 
"apiVersion": "metrics.k8s,.io/vibetai1", 
"metadata": 

"selfLink": "/apis/metrics,.k8s.io/vibetai/nodes" 





Os jq 是 专用 于 处 理 JSON 数 据 的 命令 行 工具 ， 其 功能 类 似 
于 sed 对 文本 信息 的 处 理 ， 在 CentOS 系 统 上 由 jq 程 序 包 所 提供 。 


此 外 ，Pod 对 象 的 资源 消耗 信息 也 可 以 经 由 资源 指标 API 直 接 列 出 ， 
例如 ， 要 获取 集群 上 所 有 Pod 对 象 的 相关 资源 消耗 数据 ， 可 使 用 如 下 格 


TH 








~]$ kubectl1 get --raw "/apis/metrics.k8s.io/vibetai/pods" | jq 








资源 指标 API 支 持 HPA v2 控制 器 根据 资源 指标 《如 CPU 和 内 存 使 用 
量 ) 进行 扩展 ， 但 不 支持 使 用 特定 于 应 用 程序 的 指标 ， 那 些 特定 于 应 用 
程序 的 指标 需要 依赖 于 自 定义 指标 API。 执 行 完 成 上 述 步骤 并 确认 结 
无 误 后 ，metrics-server 即 成 功 部 署 完 成 ， 那 些 依赖 于 核心 资源 指标 的 控 
制 器 、 调 度 器 及 UI 工 具 也 将 在 功能 上 得 到 进一步 的 完善 。 








14.2.2 ”kubectl top 命 令 


kubectl top 命 令 可 显示 节点 和 Pod 对 象 的 资源 使 用 信息 ， 它 依赖 于 集 
群 中 的 资源 指标 API 来 收集 各 项 指标 数据 。 它 包含 有 node 和 pod 两 个 子 命 
令 ， 可 分 别 用 于 显示 Node 对 象 和 Pod 对 象 的 相关 资源 占用 率 。 


列 出 Node 资 源 占 用 率 命 令 的 语法 格式 为 “kubectl top node[-] 
labelINAME]”， 例 如 下 面 显 示 所 有 市 点 的 资源 占用 状况 的 结果 中 显示 了 
各 节点 累计 CPU 资 源 占用 时 长 及 百分比 ， 以 及 内 容 空 间 占 用 量 及 占用 比 
例 。 必 要 时 ， 也 可 以 在 命令 中 直接 给 出 要 查看 的 特定 节点 的 标识 ， 以 及 
使 用 标签 选择 器 进行 节点 过 滤 : 











~]$ kubectl1 top node 


NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% 
master .ilinux.io 444m 11% 1127Mi 65% 
node01.ilinux.io 158m 3% 558Mi 32% 





而 名 称 空 间 级 别 的 Pod 对 象 资 源 占 用 率 的 使 用 方式 会 略 有 不 同 ， 使 
用 时 ， 一 般 应 该 限定 名 称 空 间 及 使 用 标签 选择 器 过 滤 出 目标 Pod 对 象 。 
命令 的 语法 格式 为 “kubectl top pod[NAME|-] label][--all-namespaces][-- 
containers=falseltrue]”， 例 如 ， 下 面 显 示 kube-system 名 称 空间 中 标签 
为 “k8s-app=kube-dns” 的 所 有 Pod 资 源 及 其 容器 的 资源 占用 状态 : 





~]$ kubect1 top pod -1 k8s-app=kube-dns --containers=true -n kube-system 


POD NAME CPU(cores) MEMORY (bytes) 
coredns-78fcdf6894-ncxdj coredns 3m 18Mi 
coredns-78fcdf6894-pvv88 coredns 3m 17Mi 





kubectl top 命 令 为 用 户 提 供 了 简洁 、 快 速 获取 Node 对 象 及 Pod 对 象 占 
用 系统 资源 状况 的 接口 ， 是 集群 运行 和 维护 的 常用 命令 之 一 。 


14.3” 自 定义 指标 与 Prometheus 


除了 资源 指标 之 外 ， 用 户 或 管理 员 需 要 了 解 的 指标 数据 还 有 很 多 ， 
如 Kubernetes 指 标 、 更 全 面 的 容器 指标 、 更 全 面 的 节点 资源 指标 及 应 用 
程序 指标 ， 等 等 。 自 定义 指标 API 人 允许 请 求 任 意 指 标 ， 其 指标 API 的 实 
现 要 特定 于 相应 的 后 端 监视 系统 。Prometheus 是 第 一 个 开发 了 相应 适 配 
右 的 监控 系统 ， 毕 况 它 是 监控 Kubernetes 的 第 一 选择 。 这 个 适用 于 
Prometheus 的 Kubernetes Custom Metrics Adapter 由 托管 在 GitHub 上 的 k8s- 
prometheus-adapter 项 目 提供 ， 如 图 14-7 所 示 。 
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图 14-7 自 定义 指标 


目 定 义 指标 API 的 目的 是 提供 最 终 用 户 和 Kubernetes 系 统 组 件 可 以 依 
赖 的 稳定 的 、 版 本 化 的 API， 但 其 可 用 的 实现 及 可 用 指标 则 有 赖 于 第 三 
方 或 用 户 的 自行 实现 ， 目 前 基于 Prometheus 收 集 和 存储 指标 数据 ， 并 借 
助 于 k8s-prometheus-adapter 将 这 些 指标 数据 查询 接口 转换 为 标准 的 
Kubernetes 自 定义 指标 是 较为 流行 的 解决 方案 之 一 。 








14.3.1 Prometheus 概 述 


Prometheus 是 一 个 开源 的 服务 监控 系统 和 时 序数 据 库 ， 由 社交 音乐 

台 SoundCloud 在 2012 年 开发 ， 也 是 CNCEF 除 Kubernetes 之 外 收录 的 第 二 
款 产 品 ， 目 前 已 经 成 为 Kubernetes 生 态 圈 中 的 核心 监控 系统 ， 而 且 越 来 
越 多 的 项 目 〈 如 etcd 等 ) 都 提供 了 对 Prometheus 的 原生 文 持 ， 这 足以 证 


明 社 区 对 它 的 认可 程度 。 


Prometheus 提 供 了 通用 的 数据 模型 和 便捷 的 数据 采集 、 存 储 和 得 询 
接口 。 其 核心 组 件 Prometheus 服 务 器 定期 从 静态 配置 的 监控 目标 
(targets) 或 者 基于 服务 发 现 (service discovery) 自动 配置 的 目标 中 拉 
取 数 据 ， 新 拉 取 到 的 数据 大 于 配置 内 存 缓存 区 时 ， 数 据 将 持久 化 到 存储 
设备 中 ， 包 括 远程 云端 存储 系统 。Prometheus 的 生态 组 件 架 构 如 图 14-8 


所 示 。 
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图 14-8 ”Prometheus 的 生态 组 件 架 构 


图 14-8 所 示 的 各 种 组 件 中 ， 每 个 被 监控 的 目标 〈 主 机、 应 用 程序 
等 ) 都 可 通过 专用 的 exporter 程 序 提供 输出 监控 数据 的 接口 ， 并 等 待 




















Prometheus 服 务 器 周期 性 的 数据 抓 取 操 作 。 知 存在 告警 规则 ， 则 抓 取 到 
数据 后 会 检查 并 根据 规则 进行 计算 ， 满 足 告警 条 件 即 会 生成 告警 ， 并 发 
送 到 Alertmanager 完 成 告警 的 汇总 和 分 发 等 操作 。 被 监控 目标 有 主动 推 
送 数据 的 需求 时 ， 可 部 署 Pushgateway 组 件 接收 并 临时 存储 数据 ， 并 等 
符 Prometheus 服 务 堪 完成 数据 采集 。 


任何 被 监控 的 目标 都 需要 事先 纳入 到 监控 系统 中 才能 进行 时 序数 据 
采集 、 存 储 、 告 警 及 相关 的 展示 等 ， 监 控 目 标 既 可 以 通过 配置 信息 以 王 
态 形 式 指定 ， 也 可 以 让 Prometheus 通 过 服务 发 现 机 制 动 态 管理 (增删 
等 ) ， 对 于 变动 频繁 的 系统 环境 (如 容器 云 环 境 ) 来 说 ， 这 种 动态 管理 
机 制 尤 为 有 有用。 在 Kubernetes 集 群 及 相关 的 环境 中 ， 除 了 此 前 配置 的 从 
Pod 对 象 中 的 容器 应 用 获得 资源 指标 数据 以 外 ，Prometheus 还 文 持 通过 
多 个 监控 目标 采集 Kubernetes 监 控 架 构 体 系 中 所 谓 的 “ 非 核心 指标 数 
据 *， 如 图 14-9 所 示 。 
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图 14-9 Kubernetes 中 的 Prometheus 数 据 源 
1) 监控 代理 程序 ， 如 node_exporter， 


收集 标准 的 主机 指标 数据 ， 包 括 平均 负载 、CPU、Memory、 
Disk、Network 及 诸多 其 他 维度 的 数据 ， 独 立 的 指标 可 能 多 达 上 干 个 。 


2) kubelet (cAdvisor) : 收集 容器 指标 数据 ， 它 们 也 是 所 谓 的 
Kubernetes“ 核 心 指标 ?， 每 个 容器 的 相关 指标 数据 主要 有 CPU 利 用 率 
Cuser 和 system) 及 限额 、 文 件 系统 读 / 写 限额 、 内 存 利用 率 及 限额 、 网 
络 报 文 发 送 /接收 /丢弃 速率 等 。 


3) API Server: 收集 API Server 的 性 能 指标 数据 ， 包 括 控制 工作 队 
列 的 性 能 、 请 求 速率 与 延迟 时 长 、etcd 绥 存 工作 队列 及 缓存 性 能 、 普 通 





进程 状态 〈 文 件 描述 符 、 内 存 、CPU 等 ) 、Golang 状 态 〈GC、 内 存 和 
线程 等 ) 。 


4) etcd: 收集 etcd 存 储 集群 的 相关 指标 数据 ， 包 括 领导 节点 及 领域 
变动 速率 、 提 交 / 应 用 / 挂 起 /错误 的 提案 次 数 、 人 磁盘 写 入 性 能 、 网 络 与 
gRPC 计 数 器 等 。 


5) kube-state-metrics: 此 组 件 能 够 派生 出 Kubernetes 相 关 的 多 个 指 
标 数 据 ， 主 要 是 资源 类 型 相关 的 计数 器 和 元 数据 信息 ， 包 括 指定 类 型 的 
对 象 忌 数 、 资 源 限额 、 容 问 状 态 
Cready/restartrunning/terminated/waiting) 以 及 Pod 资 源 的 标签 系列 等 。 


Prometheus 能 够 直接 把 Kubernetes API Server 作 为 服务 发 现 系统 使 用 
进而 动态 发 现 和 监控 集群 中 的 所 有 可 被 监控 的 对 象 。 这 里 需要 特别 说 明 
的 是 ，Pod 资 源 需 要 添加 下 列 注解 信息 才能 被 Prometheus 系 统 上 自动 发 现 
并 抓 取 其 内 建 的 指标 数据 。 


1) prometheus.io/scrape: 用 于 标识 是 售 需 要 被 采集 指标 数据 ， 布 尔 
型 值 ，true 或 false。 


2) prometheus.io/path: 抓 取 指标 数据 时 使 用 的 URL 路 径 ， 一 般 


为 /metrics。 


3) prometheus.io/port: 抓 取 指标 数据 时 使 用 的 套 接 字 端口 ， 如 
8080。 


另外 ， 仅 期 望 Prometheus 为 后 端 生 成 自 定 义 指 标 时 仅 部 署 
Prometheus 服 务 器 即 可 ， 它 甚至 也 不 需要 数据 持久 功能 。 但 和 若 要 配置 完 
整 功能 的 监控 系统 ， 管 理 员 还 需要 在 每 个 主机 上 部 署 node_exporter、 按 
需 部 署 其 他 特有 类 型 的 exzporter 以 及 Alertmanager。 











14.3.2” ”部署 Prometheus 监 控 系 统 


为 了 便于 用 户 快 速 集成 一 个 完整 的 Prometheus 监 控 环 境 ， 
Kubernetes 源 代码 的 集群 附件 目录 中 统一 提供 了 Prometheus、 
Alertmanager、node_exporter 和 kube-state-metrics 相 关 的 配置 清单 ， 路 径 
为 clusteraddons/prometheus， 每 个 项 目的 配置 清单 不 止 一 个 且 文 件 都 以 
项 目 名 称 开 起 。 将 Kubernetes 源 码 仓 库 元 隆 至 本 地 ， 以 便 在 后 面 的 各 配 
置 步骤 中 应 用 其 配置 文件 : 





~]$git clone https://github.com/kubernetes/kubernetes.git 





为 了 便于 读者 理解 和 排除 问题 ， 下 面 分 步骤 分 别 说 明 kube-state- 
metrics、node_exporter、Alertmanager 和 Prometheus 四 个 组 件 的 部 署 过 
程 。 


1. 生 成 集群 资源 状态 指标 


kube-state-metrics 能 够 从 Kubernetes API Server 上 收集 各 大 多 数 资源 
对 象 的 状态 信息 并 将 其 转 为 指标 数据 ， 它 工作 于 HTTP 的 /metrics 接 口 ， 
通过 Prometheus 的 Go 语言 客户 端 暴 圳 于 外 ，Prometheus 系 统 以 及 任何 兼 
容 相关 客户 端 接口 的 数据 抓 取 工具 都 可 采集 相关 数据 ， 并 了 予以 存储 或 展 
示 。 因 此 ， 再 结合 Prometheus 的 其 他 指标 数据 采集 接口 及 报警 功能 ， 用 
户 可 于 Kubernetes 构 建 出 一 个 自 定义 指标 API Server 的 同时 提供 一 个 完整 
的 监控 系统 。 


kube-state-metrics 是 Kubernetes 集 群 的 一 个 附加 组 件 ， 它 通过 
Kubernetes API service 监 昕 资源 对 象 的 状态 并 生成 相关 的 指标 ， 不 过 ， 
它 不 在 意 单个 Kubernetes 组 件 的 运行 状况 ， 而 是 关注 内 部 各 种 对 象 的 整 
体 运 行 状况 ， 如 Deployment 对 象 或 ReplicaSet 对 象 等 。 换 名 话说，kube- 
state-metrics 的 重点 是 从 Kubernetes 的 对 象 状 态 生成 全 新 的 指标 。 


最 初 ，kube-state-metrics 是 作为 Heapster 的 另 一 个 指标 数据 源 而 开发 
的 ，Heapster 只 需要 获取 、 格 式 化 和 转发 原本 就 存在 的 指标 ， 特 别 是 
Kubernetes 组 件 的 指标 ， 并 将 它们 写 入 接收 右 即 可 。 相 比 之 下 ，kube- 
state-metrics 在 内 存 中 保存 了 Kubernetes 系 统 状 态 的 完整 快照 ， 并 不 断 生 























但 不 负责 在 任何 地 方 导 出 指标 ， 那 是 Heapster 的 任 


不 过 ， 有 些 监控 系统 〈 如 Prometheus) 根本 不 使 用 Heapster 进 行 指 
标 数据 收集 ， 而 是 目 我 实现 了 特有 的 收集 方式 ， 因 此 ， 将 kube-state- 
metrics 作 为 单独 的 项 目 ， 可 以 让 Prometheus 这 类 监视 系统 访问 也 能 使 用 
由 它 提供 的 指标 。 目 前 ，kube-state-metrics 主 要 负责 为 CronJob、 
Deployment、PersistentVolumeClaim 等 各 类 型 的 资源 对 象 生 成 指标 数 
据 ， 各 类 资源 类 型 生成 的 指标 的 功能 及 用 法 请 参考 相关 的 文档 ， 地 址 为 


https://github.com/kubernetes/kube-state-metrics/tree/master/Documentation 


将 工作 目录 切换 到 元 隆 至 本 地 的 Kubernetes 项 目 源码 的 
clusteraddons/prometheus 目 录 中 ， 将 所 有 文件 名 以 kube-state-metrics 相 关 
的 配置 清单 创建 于 集群 中 即 能 完成 部 署 : 








~]$ cd kubernetes/cluster/addons/prometheus/ 
~]$ for file in kube-state-*; do kubectl1 apply -f $file; done 





部 蜀 完 成 后 会 于 kube-system 名 称 空间 创建 一 个 名 为 kube-state- 
metrics 的 Deployment 控 制 嚣 对象， 其 所 生成 的 Pod 对 象 中 的 容器 应 用 将 
监听 于 8080 和 8081 端 口 以 提供 指标 数据 ， 除 此 之 外 ， 还 会 在 kube-system 
名 称 空间 中 创建 一 个 同名 的 Service 对 象 为 客户 端 提供 固定 的 访问 入 口 ， 
用 户 也 可 以 通过 任何 类 型 的 HTTP 客 户 端 程序 测试 访问 其 原始 格式 的 指 
标 及 数据 。 例 如 ， 启 动 一 个 Pod 客 户 进行 访问 测试 ， 命 令 如 下 : 





~]$ kubectl1 run client-$RANDOM --image=cirros -it --rm -- sh 

/# curl -s kube-state-metrics.kube-system:8080/metrics | tail 

# HELP kube_service_spec_type Type about service. 

# TYPE kube_service_spec_type gauge 

kube_service_ spec_type{namespace="default", service="kubernetes",type="ClusterIP"} 1 





分 别 通 过 8080 和 8081 端 口 进行 确认 能 各 上 自得 到 一 系列 的 指标 数据 ， 
即 表 示 kube-state-metrics 准 备 就 绪 。 


2.ExporterR Node Exporter 


Prometheus 通 过 HTTP 周 期 性 抓 取 指 标 数据 ， 监 控 目 标 上 用 于 接收 
并 响应 数据 抓 取 请 求 的 组 件 统称 为 exporter。 目 前 ，Prometheus 项 目 及 社 
区 提供 了 众多 现成 可 用 的 exporter， 分 别 用 于 监控 操作 系统 、 数 据 库 、 
便 件 设 备 、 消 息 队 列 、 存 储 系统 等 类 型 的 多 种 目标 对 象 。 


@ 提示 。 Prometheus 的 常用 exporter 列 表 位 于 


https://prometheus.io/docs/instrumenting/exporters/ 。 


在 监控 目标 系统 上 ，Exporter 将 收集 的 数据 转化 为 文本 格式 ， 并 通 
过 HTITP 对 外 暴露 相应 的 接口 ， 它 不 会 局 限于 任何 编程 语言 或 实现 方 
式 ， 只 需要 它 能 够 接收 来 自 Prometheus 服 务 器 端的 数据 抓 取 请 求 ， 并 以 
特定 格式 的 数据 进行 啊 应 ， 因 此 它 尤 其 适用 于 容器 环境 。 


.Exporter 的 啊 应 内 容 以 行为 单位 ， 其 中 ， 以 “#HELP” 开 头 的 是 注释 
信息 用 于 提供 指标 说 明 ， 以 “#TYPE” 开 头 的 注释 行 用 于 指明 当前 指标 的 
类 型 ， 它 可 以 是 counter、gauge、histogram 或 summary 其 中 之 一 ; 空白 行 
将 被 忽略 。 


:每 一 个 非 注 释 行 都 是 一 个 键 值 类 型 的 数据 ， 其 键 即 是 指标 ， 相 应 
的 值 是 当前 指标 本 次 啊 应 的 float 类 型 的 数据 ， 寿 返回 的 值 有 两 个 ， 则 最 
de 啊 应 值 必须 要 用 双 引 号 进行 引用 ， 人 否则 即 为 格 
式 错 误 。 


Prometheus 为 监控 类 UNIX 操 作 系 统 提 供 了 一 个 专用 的 node_exporter 
程序 ， 它 能 够 收集 多 种 系统 级 指标 ， 如 conntrack、cpu、diskstats、 
meminfo、filesystem、netstat 和 socketstats 等 数 十 种 。node_exporter 运 行 
为 守护 进程 监听 于 节点 上 的 9100 端 口 ， 通 过 URL 路 径 /metrics 提 供 指标 
数据 ，Prometheus 服 务 器 可 在 配置 文件 中 使 用 静态 配置 监控 每 一 个 运行 
node_exporter 的 目标 主机 ， 也 能 够 使 用 基于 文件 、Consul、DNS、 
Kubernetes 等 多 种 服务 发 现 机 制 动 态 添 加 监控 对 象 。 


事实 上 ， 监 控 Kubernetes 集 群 时 ， 每 个 节点 本 身 就 能 通过 kubelet 或 
CAdvisor 提 供 符合 Prometheus 规 范 的 节点 指标 数据 ， 因 此 也 可 以 不 安装 
node_exporter 程 序 ， 甚 至 Kubernetes 为 部 署 Prometheus 服 务 堪 提供 的 配置 
清单 中 也 没有 加 载 各 节点 exporter 上 的 指标 。 不 过 ， 用 户 也 完全 可 以 部 
署 并 自行 配置 通过 node_exporter 进 程 节点 进行 监控 。 























在 此 前 克隆 的 Kubermetes 源 码 目录 的 cdluster/addons/prometheus 路 径 
下 执行 如 下 命令 便 可 完成 在 集群 中 各 节点 上 部 署 并 运行 node_exporter， 
它 将 以 DaemonSet 控 制 器 对 象 于 各 节点 中 运行 一 个 相应 的 Pod 资 源 : 





~]$ cd kubernetes/cluster/addons/prometheus/ 
~]$ for file in node-exporter-*; do kubectl1 apply -f $file; done 





node_exporter 相 关 的 各 Pod 对 象 共享 使 用 其 所 在 节点 的 网 络 名 称 空 
间 ， 它 直接 监听 于 相关 地 址 的 9100 端 点 ， 因 此 可 直接 对 其 中 某 一 个 节点 
发 起 请 求 测试 : 











~]$ curl node01.ilinux.io:9100/metrics 

# HELP process_virtual memory_bytes Virtual memory size in bytes. 
# TYPE process_virtual memory_bytes gauge 

process_virtual memory_bytes 1.38784768e+08 





上 面 显示 的 命令 啊 应 结果 中 ， 指 标 名 称 为 
process_virtual_ memory_bytes， 相 应 值 为 oat 格 式 ， 前 面 两 行 分 别 是 帮 
助 信息 及 指标 类 型 说 明 。 


3. 告 警 系统 Alertmanager 


Prometheus 的 告警 功能 由 两 个 步 又 实现 ， 首 先是 Prometheus 服 务 右 
根据 告警 规则 将 告警 信息 发 送 给 Alertmanager， 而 后 由 Alertmanager 对 收 
到 的 告警 信息 进行 处 理 ， 包 括 去 重 、 分 组 并 路 由 到 告警 接收 端 ， 支 持 的 
形式 包括 slack、email、pagerduty、hitchat 和 WebHook 等 接口 上 的 联系 人 


日 /to 


下 面 的 配置 文件 片断 取 自 kubernetes 源 人 码 目录 中 的 
cluster/addons/prometheus/alertmanager-configmap.yaml 文 件 ， 它 是 一 个 
ConfigMap 对 象 ， 用 于 为 运行 于 Pod 中 的 Alertmanager 提 供 配 置信 息 : 














global: null 
receivers: 
- name: default-receiver 
route: 
group_interval: 5m 
group_wait: 10s 
receiver: default-receiver 
repeat_interval: 3h 








上 面 的 配置 信息 非常 简洁， 全 局 配置 参数 〈global) 为 空 ， 告 警 接 
收 端 (receivers) 只 有 一 个 default-receiver， 路 由 (route) 逻辑 是 将 告警 
信息 和 暂 存 5 分 钟 后 进行 发 送 ， 且 每 隔 3 小 时 重复 一 次 。 实 际 应 用 中 需要 提 
供 的 配置 请 读者 参考 Alertmanager 的 相关 文档 。 


Prometheus 附 件 的 配置 清单 中 ，Alertmanager 的 Deployment 对 象 配 置 
容器 使 用 了 持久 存储 卷 ， 它 定义 在 Pod 模 板 中 ， 存 储 卷 类 型 为 
persistentVolumeClaim， 因 此 部 车 前 需要 确保 能 为 其 提供 使 用 的 存储 


另外 ，Alertmanager 的 守护 进程 通过 9093 闯 口 提 供 了 一 个 Web UJ， 
用 于 检查 和 过 滤 告 警 信息 。 如 需 于 Kubernetes 集 群 之 外 访问 此 接口 ， 这 
里 选择 将 其 Service 对 象 设 定 为 NodePort 类 型 ， 并 绑 定 固定 的 30093 端 
口 ， 配 置 片 断 如 下 所 示 : 

















spec: 
ports: 
- name: http 
port: 80 
protocol: TCP 
targetPort: 9093 
nodePort: 30093 
selector: 
k8s-app: alertmanager 
type: "NodePort" 





待 条 件 满足 后 ， 即 可 部 署 Alertmanager: 





~]$ cd kubernetes/cluster/addons/prometheus/ 
~]$ for file in node-exporter-*; do kubectl1 apply -f $file; done 











部 悍 完 成 后 打开 其 Web UI 即 可 过 滤 和 得 看 告警 信息 ， 主 界面 如 图 
14-10 所 示 。 





€ S&H | 172.160.66:30093/#/alerts 





Alertmanager Alerts Silences Status New Silence 


Fiter | Group Receiver: All Silenced Inhibited 


Custom matcher, e.g. env= "production” 





图 14-10 ”Alertmanager 的 Web UI 
4. 部 署 Prometheus 服 务 器 


Prometheus 服 务 器 是 整个 监控 系统 的 核心 ， 它 通过 各 exporter 周 期 性 
采集 指标 数据 ， 存 储 于 本 地 的 TSDB (Time Series Database ) 后 端 存储 
系统 中 ， 并 通过 PromQL 向 客户 端 提 供 查 询 接口 。 


由 Kubernetes 项 目 提供 的 附件 配置 清单 中 ，Prometheus 使 用 
StatefulSet 配 置 对 象 ， 各 Pod 对 象 通过 volumeClaimTemplates 对 象 申 请 使 
用 持久 存储 卷 ， 因 此 部 普 前 需要 确保 能 为 其 提供 使 用 的 存储 疮 。 另 外 ， 
Prometheus 也 提供 了 Web UI， 通 过 9090 端 口 输出 ， 测 试 使 用 时 ， 可 以 配 
置 其 通过 NodePort 类 型 的 Service 对 象 进行 输出 : 








~]$ cd kubernetes/cluster/addons/prometheus/ 
~]$ for file in prometheus-*; do kubectl1 apply -f $file; done 





确认 各 相关 资源 对 象 得 以 正确 创建 ， 且 相关 的 Pod 都 能 正常 运行 无 
误 后 即 完成 部 署 。 此 时 ， 于 Prometheus 的 Web GUI 的 Targets 状 态 页 面 中 
可 看 到 相关 节点 的 发 现 结果 ， 如 图 14-11 所 示 。 








€ 3 C&C O|D 172.160.66:30090/targets 


Status ~ 


Runtime & Build Information 


Ta rg ets Command-Line Flags 


Configuration 
| © only unhealthy jobs 
L Rules 


kubernetes-apiservers (1/ | ee 


Service Discovery 
Endpoint 一 me 一 一 


httpsJ1172.31.143.64:6443/metrics UP 


kubernetes-nodes-cadvisor (4/4 up) EEE 


Endpoint State Last Scrape 


https://172.31.143.64:10250/metrics/cadvisor UP 8.009s ago 


https://172.31.143.65:10250/metrics/cadvisor 13.063s ago 





图 14-11 Prometheus 的 监控 目标 


PromQL (Prometheus Query Language) 是 Prometheus 专 有 的 数据 查 
询 语 言 (DSL) ， 其 提供 了 简洁 且 贴 近 自 然 语言 的 语法 实现 了 时 序数 据 
的 分 析 计 算 能 力 。PromQL 表 现 力 丰 富 ， 文 持 条 件 人 查询 、 操 作 符 ， 并 且 
内 建 了 大 量 内 置 函 数 ， 可 供 客户 端 针对 监控 数据 的 各 种 维度 进行 查询 。 
PromQL 的 使 用 方式 请 参考 相关 的 文档 或 书籍 。 








14.3.3 ”上 自 定义 指标 适配器 k8s-prometheus-adapter 


Prometheus 提 供 的 PromQL 接 口 无 法 直接 作为 自 定 义 指标 数 据 源 ， 
它 并 非 Kubernetes 系 统 的 聚合 API 服 务 器 ， 它 们 之 间 还 需要 一 个 中 间 
层 “Kubernetes Custom Metrics Adapter for Prometheus”， 目 前 最 流行 的 自 
定义 指标 适配器 是 托管 于 Github 之 上 的 k8s-prometheus-adapter 项 目 。 


自 定 义 的 Kubernetes API Server 必 须要 基于 HTTPS 与 客户 端 进行 通 
言 ， 因 此 为 了 便于 部 署 ， 这 些 程序 大 多 数 会 生成 一 个 自 签 证 书 。 不 过 ， 
k8s-prometheus-adapter 项 目 提供 的 配置 清单 要 使 用 一 个 名 为 cm-adapter- 
serving-certs 的 Secret 对 象 加 载 由 用 户 自 行 提 供 的 证 书 。 于 是 ， 部 署 之 前 
需要 以 合理 的 方式 生成 证 书 并 配置 为 Secret 对 象 。 这 里 选择 以 Master 主 
机 系统 管理 员 的 身份 基于 Kubernetes 的 CA 为 其 签署 一 个 自制 证 书 : 








~]# cd /etc/kubernetes/pki/ 
~]# (umask 077; openssl genrsa -out serving.key 2048) 
~]# openssl red -new -key serving.key -out serving.csr -Subj "/CN=serving" 
~]# openssl x509 -req -in serving.csr -CA /etc/kubernetes/pki/ca.crt \ 
-CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out serving.crt -days 3650 





k8s-prometheus-adapter 默 认 会 部 普 在 custom-metrics 名 称 空间 ， 因 此 
需要 将 相关 证 书 和 私 钥 作 为 此 名 称 空 间 中 的 Secret 对 象 。 





Os 证 书 和 私 钥 两 个 数据 项 的 相应 键 名 必须 为 serving.crt 和 和 


SerVing.key。 





~]$ kubectl create namespace custom-metrics 
~]$ kubectl1 create secret generic cm-adapter-serving-certs -n custom-metrics \ 
--from-file=serving.crt=,./serving.crt --from-file=serving.key=./serving.key 





确认 创建 完成 后 即 可 部 署 k8s-prometheus-adapter， 部 署 清单 位 于 项 
目 源 代码 的 deploy 目 录 中 。 元 隆 到 相关 的 代码 并 将 资源 创建 于 集群 中 即 
可 : 





~]$ git clone https://github.com/DirectXMan12/k8s-prometheus-adapter .git 
~]$ kubectl1 apply -f Kk8s-prometheus-adapter/deploy/manifests/ 





资源 创建 过 程 中 会 在 kube-aggregator 上 注册 新 的 API 群 组 
custom.metrics.k8s.io， 待 相关 的 Pod 对 象 转 为 正常 运行 状态 之 后 即 可 通 
过 kubectl api-versions 命 令 确 认 其 API 接 口 注册 的 结果 : 





~]$ kubect1l api-versions | grep custom 
custom,.metrics.k8s.io/vibetai 





癌 custom.metrics.k8s.io 群 组 直接 发 送 请 求 即 可 列 出 其 可 用 的 所 有 自 
定义 指标 ， 例 如 ， 这 里 使 用 “kubectl get--raw” 命 令 进 行 测试 ， 并 使 用 jq 
命令 过 滤 结 果 ， 仅 列 出 指标 名 称 : 





~]$ kubectl1 get --raw "/apis/custom.metrics,k8s,Io/v1betal"” | jq '.resources[].name' 
"pods/kube_pod_container_status_running" 
"pods/kube_pod_info" 





另外 ， 也 可 以 直接 通过 API 碍 看 指定 的 Pod 对 象 的 相应 指标 及 其 值 ， 
例如 ， 可 以 使 用 类 似 如 下 的 命令 列 出 kube-system 名 称 空间 中 的 所 有 Pod 
对 象 的 文件 系统 占用 率 : 





~]$ kubect1 get --raw \ 
"/apis/custom.metrics,.k8s.io/vibetai/namespaces/kube-system/pods/*/memotry_usage_ 
bytes" | jq.. 





上 面 的 命令 会 列 出 相应 名 称 空间 中 所 有 Pod 对 象 的 内 存 资 源 占用 状 
况 ， 一 个 数据 项 的 显示 结果 足以 了 解 其 啊 应 格式 ， 例 如 下 面 的 内 容 截 取 
自命 令 结果 中 关于 coredns 的 Pod 对 象 的 相关 输出 : 





"describedOobject": { 
"kind": "Pod", 
"namespace": "kube-system", 
"name": "coredns-78fcdf6894-cft19", 
"apiVersion": "/__internal" 
}, 
"metricName": "memory_usage_ bytes", 
"timestamp": "2018-08-28T04:54:322", 
"value": "40189952" 
} 


ee | 


14.4 有 目 动 弹性 缩放 


Deployment、ReplicaSet、Replication Controller 或 StatefulSet 控 制 器 
资源 管控 的 Pod 副 本 数量 文 持 手动 方式 的 运行 时 调整 ， 从 而 更 好 地 匹配 
业务 规模 的 实际 需求 。 不 过 ， 手 动 调整 的 方式 依赖 于 用 户 深 度 参 与 监控 
容器 应 用 的 资源 压力 并 且 需 要 计算 出 合理 的 值 进 行 调整 ， 存 在 一 定 程 度 
的 清 后 性 。 为 此 ，Kubernetes 提 供 了 多 种 上 自动 弹性 伸缩 (Auto Scaling) 
工具 ， 上 其 体 如 下 。 





RC/Deployment 





图 14-12 ” HPA 控制 器 示意 图 





.HPA: 全 称 Horizontal Pod Autoscaler， 一 种 支持 控制 器 对 象 下 Pod 
规模 弹性 伸缩 的 工具 ， 目 前 有 两 个 版 本 的 实现 ， 分 别称 为 HPA 和 
HPA (v2) ， 前 一 种 仅 文 持 把 CPU 指标 数据 作为 评估 基准 ， 而 新 版 本 文 
持 可 从 资源 指标 API 和 自 定 义 指标 API 中 获取 的 指标 数据 。HPA 控 制 器 
示意 图 如 图 14-12 所 示 。 


:CA: 全 称 Cluster Autoscaler， 是 集群 规模 自动 弹性 伸缩 工具 ， 能 上 自 
动 增 减 GCP、AWS 或 Azure 


.集群 上 部 署 的 Kubernetes 集 群 的 节点 数量 ，GA 上 所 本 自 Kubernetes 
1.8 起 可 用 。 


:VPA: 全 称 Vertical Pod Autoscaler， 是 Pod 应 用 垂直 伸缩 工具 ， 它 
通过 调整 Pod 对 象 的 CPU 和 内 存 资 源 需求 量 完成 扩展 或 收缩 ， 目 前 仍 处 
于 alpha 阶 段 。 


AR: 全称 Addon Resizer， 是 一 个 简化 版 本 的 Pod 旋 用 垂直 伸缩 工 
有 具 ， 它 基于 集群 中 的 节点 数量 来 调整 附加 组 件 的 资源 需求 量 ， 当 前 仍 处 
于 beta 级 别 。 








14.4.1 HPA 概 述 


尽管 Cluster Autoscaler 高 度 依赖 基础 云 计算 环境 的 底层 功能 ， 但 
HPA、VPA 和 AR 可 以 独立 于 IaaS 或 PaaS 云 环境 运行 。HPA 可 作为 
Kubernetes API 资 源 和 控制 器 实现 ， 它 基于 采集 到 的 资源 指标 数据 来 调 
整 控制 占 的 行为 ， 控 制 器 会 定期 调整 ReplicaSets 或 Deployment 控 制 器 对 
和 的 副本 数 ， 以 使 得 观察 到 的 平均 CPU 利用 率 与 用 户 指 定 的 目标 相 匹 

Bs 


HPA 自 身 是 一 个 控制 循环 (control loop) 的 实现 ， 其 周期 由 
controller-manager 的 --horizontal-pod-autoscaler-sync-period 选 项 来 定义 ， 
默认 为 30 秒 。 在 每 个 周期 内 ，controller-manager 将 根据 每 个 HPA 定 义 中 
指定 的 指标 得 询 相应 的 资源 利用 率 。controller-manager 从 资源 指标 
API《〈 针 对 每 个 Pod 资 源 指 标 ) 或 目 定 义 指 标 API (针对 所 有 其 他 指标 ) 
中 获取 指标 数据 。 


.对 于 每 个 Pod 资 源 指标 〈 如 CPU) ， 控 制 器 都 将 从 HPA 定 位 到 的 每 
个 Pod 的 资源 指标 API 中 获取 指标 数据 。 知 设置 了 目标 利用 率 (target 
utilization ) 标准 ， 则 HPA 控 制 句 会 计算 其 实际 利用 率 
Gutilized/requests) 。 知 设置 的 是 目标 原始 值 ， 则 直接 使 用 原始 指标 
值 。 然 后 控制 器 获取 所 有 目标 Pod 对 象 的 利用 率 或 原始 值 的 均值 《取决 
于 指定 的 目标 类 型 ) ， 并 生成 一 个 用 于 缩放 所 需 副本 数 的 比率 。 不 过 ， 
对 于 未 定义 资源 需求 量 的 Pod 对 象 ，HPA 控 制 器 将 无 法 定义 该 容器 的 
CPU 利用 率 ， 并 且 不 会 为 该 指标 采取 任何 操作 。 


.对 于 每 个 Pod 对 象 的 自 定 义 指 标 ，HPA 控 制 器 的 功能 与 每 个 Pod 资 
源 指标 的 处 理 机 制 类 似 ， 只 是 它 仅 能 够 处 理 原 始 值 而 非 利用 率 。 


不 过 ， 使 用 HPA 控 制 句 管理 Pod 对 象 副本 规模 时 ， 由 于 所 评估 指标 
的 动态 变动 特性 ， 副 本 数量 可 能 会 频繁 流动， 这 种 现象 有 时 也 称 为 “ 持 
动 ”。 从 Kubernetes 1.6 版 本 开始 ， 集 群 管理 员 可 以 通过 调整 kube- 
controller-manager 的 选项 值 定 义 其 变动 延迟 时 长 来 缓解 此 问题 。 目 前 ， 
默认 的 缩 容 延迟 时 长 为 5 分 钟 ， 而 扩容 延迟 时 长 为 3 分 钟 。 


HPA 控 制 器 可 以 通过 两 种 不 同 的 方式 获取 指标 : Heapster 和 REST 客 
户 端 接口 。 使 用 直接 Heapster 获 取 指 标 数 据 时 ，HPA 和 直接 通过 API 服 务 器 









































的 服务 代理 子 资源 向 Heapster 发 起 查询 请 求 ， 因 此 ，Heapster 需 要 事先 部 
署 在 群集 上 并 在 kube-system 名 称 空 间 中 和 运行。 使 用 REST 客 户 端 接口 获 
取 指 标 时 ， 需 要 事先 部 署 好 资源 指标 API 及 其 API Server， 必 要 时 ， 还 应 
该 部 晋 好 自 定 义 指 标 API 及 其 相关 的 API Server。 


HPA 是 Kubernetes autoscalingAPI 群 组 中 的 API 资 源 ， 当 前 的 稳定 版 
本 仅 文 持 CPU 自 动 缩 放 ， 它 位 于 autoscaling/v1 群 组 中 。 而 测试 版 本 包含 
对 内 存 和 自 定义 指标 的 扩展 支持 ， 测 试 版 本 位 于 API 群 组 
autoscaling/v2betal 之 中 。 


另外 ， 目 Kubernetes 1.6 版 本 起 还 为 HPA 增 加 了 基于 多 个 指标 的 扩展 
支持 ， 用 户 可 以 使 用 autoscaling/v2betalAPI 版 本 为 HPA 配 置 多 个 指标 以 
控制 规模 伸缩 。 运 行 时 ，HPA 控 制 器 将 评估 每 个 指标 ， 并 基于 每 个 指标 
分 别 计算 出 各 目 控 制 下 的 新 的 Pod 规 模 数 量 ， 结 果 值 最 大 的 即 为 采用 的 
新 规模 标准 。 











14.4.2 HPA (v1) 控制 器 


HPA 也 是 标准 的 Kubernetes API 资 源 ， 其 基于 资源 配置 清单 的 管理 
方式 同 其 他 资源 相同 。 另 外 ， 它 还 有 一 个 特别 的 “kubectl autoscale” 命 令 
用 于 快速 创建 HPA 控 制 器 。 例 如 ， 首 先 创 建 一 个 名 为 myapp 的 
0 

砚 模 ; 








~]$ kubectl1 run myapp --image=ikubernetes/myapp:v1 --replicas=2 \ 
--requests='cpu=50m,memory=256Mi' --limits='cpu=50m,memory=256Mi"' \ 
--labels='app=myapp' --expose --port=80 

~]$ kubect1 autoscale deploy myapp --min=2 --max=5 --cpu-percent=60 





通过 命令 创建 的 HPA 对 象 隶 属于 “autoscaling/v1” 群 组 ， 因 此 ， 它 仪 
文 持 基于 CPU 利用 率 的 弹性 伸缩 机 制 ， 可 从 Heapster 或 Metrics Service 获 
得 相关 的 指标 数据 。 下 面 的 命令 用 于 显示 HPA 控 制 器 的 当前 状态 : 





~]$ kubectl1 get hpa myapp -0 yaml 
apiVersion: autoscaling/v1 
kind: HorizontalPodAutoscaler 
metadata: 
spec: 
maxReplicas: 5 
minReplicas: 2 
scaleTargetRef: 
apiVersion: extensions/vibetal 
kind: Deployment 
name: myapp 
targetcPUUtilizationpercentage: 60 
status: 
currentCPUUtilizationPercentage: 0 
currentReplicas: 2 
desiredReplicas: 2 





HPA 控 制 器 会 试图 让 Pod 对 象 相应 资源 的 占用 紊 无 限 接近 设 定 的 目 
标 值 。 例 如 ， 癌 myapp-svc 的 NodePort 发 起 持续 性 的 压力 测试 式 访问 请 
求 ， 各 Pod 对 象 的 CPU 利用 率 将 持续 上 升 ， 直 到 超过 目标 利用 率 边 界 的 
60%， 而 后 触发 增加 Pod 对 象 副本 数量 。 待 其 资源 占用 率 下 降 到 必须 要 
降低 Pod 对 象 的 数量 以 使 得 资源 占用 率 靠 近 目 标 设 定 值 时 ， 即 触发 Pod 副 
本 的 终止 操作 ， 如 图 14-13 所 示 。 
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图 14-13 HPA 监控 指标 计算 


下 面 是 HPA 控 制 器 myapp 在 其 详细 信息 “Events” 中 的 一 段 内 容 ， 它 
显示 了 因 资 源 占 用 率 过 高 而 增加 Pod 副 本 数量 ， 以 及 资源 占用 率 较 低 而 
降低 Pod 副 本 数量 的 部 分 操作 事件 : 





Events: 

Type Reason Age From Message 

Normal SuccessfulRescale 39m (x3 over 1h) horizontal-pod-autoscaler New size: 
5; reason: cpu resource utilization (percentage of request) above target 

Normal SuccessfulRescale 8m (x2 over 42m) horizontal-pod-autoscaler New 
size: 4; reason: All metrics below target 

Normal SuccessfulRescale 3m horizontal-pod-autoscaler New 
size: 2; reason: All metrics below target 





当然 ， 用 户 可 以 通过 资源 配置 清单 定义 HPA (v1) 控制 絮 资 源 ， 其 
spec 字 上 段 藤 套 使 用 的 属性 字段 主要 包 售 maxReplicas、minReplicas、 
scaleTargetRef 和 targetCPUUtilization-Percentage 儿 个 ， 其 使 用 方式 请 参 
考 相 应 的 文档 获取 。 尽 管 CPU 资源 利用 率 可 以 作为 规模 伸缩 的 评估 标 
a 0k Pod 对 象 所 面临 的 访问 压力 未 必 会 直接 反映 到 CPU 
乙 上 。 


14.4.3 HPA (v2) 控制 器 





HPA (v2) 控制 器 支持 基于 核心 指标 CPU 和 内 存 资源 以 及 基于 任意 
自 定 义 指 标 资源 占用 状态 实现 应 用 规模 的 自动 弹性 伸缩 ， 它 从 metrics- 
server 中 请 求 查 看 核心 指标 ， 从 k8s-prometheus-adapter 一 类 的 自 定 义 API 
中 获取 自 定义 指标 数据 ， 如 图 14-14 所 示 。 
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图 14-14 HPA (v2) 的 数据 指标 获取 方式 


下 面 是 一 个 HPA (v2) 控制 器 的 资源 配置 清单 示例 〈hpa-V2- 
resources.yaml) ， 它 使 用 资源 指标 API 获 取 两 个 指标 CPU 和 内 存 资 源 的 
使 用 状况 ， 并 与 其 各 上 自 的 设 定 目标 进行 比较 ， 计 算得 出 所 需要 的 副本 数 
量 ， 两 个 指标 计算 的 结果 中 数值 较 大 的 胜出 : 


apiVersion: autoscaling/v2beta1i 
kind: HorizontalPodAutoscaler 
metadata: 
name: myapp 
spec: 
scaleTargetRef: 
apiVersion: apps/vi1 
kind: Deployment 
name: myapp 
minReplicas: 2 
maxReplicas: 10 
metrics: 
- type: Resource 
resource: 
name: cpu 
targetAverageUtilization: 50 
- type: Resource 
resource: 
name: memor 
targetAverageValue: 5OMi 








将 配置 清单 中 的 资源 创建 于 集群 中 即 可 进行 应 用 规模 伸缩 测试 ， 其 
测试 方式 与 14.4.2 节 中 的 过 程 相似 ， 这 里 不 再 给 出 其 具体 的 过 程 。 细 心 
的 读者 或 许 已 经 注意 到 ，HPA 〈v2) 尚且 处 于 beta 阶 段 ， 将 来 它 有 可 能 
会 发 生 部 分 改变 ， 但 目前 的 特性 足以 支撑 起 其 核心 功能 。HPA 〈v2) 控 
制 器 的 创建 语法 遵循 标准 的 API 资 源 格式 ， 由 apiVersion、kind、 
metadata 和 spec 字 段 组 成 ， 其 中 spec 字 段 主要 肉 套 使 用 如 下 几 个 字段 。 


-minReplicas<integer>: 自动 伸缩 可 缩减 至 的 Pod 副 本 数 下 限 。 


-maxReplicas<integer>: 自动 伸缩 可 扩展 至 的 Pod 副 本 数 上 限 ， 其 值 
不 能 低 于 min-Replicas 属 性 值 。 


“scaleTargetRef<object>: 要 缩放 的 目标 资源 ， 以 及 应 该 收集 指标 数 
据 并 更 改 其 副本 数量 的 Pod 对 象 ， 引 用 目标 对 象 时 ， 主 要 会 用 到 三 个 区 
套 属性 一 apiVersion、kind 和 name。 


-metrics<[]object>: 用 于 计算 所 需 Pod 副 本 数量 的 指标 列表 ， 每 个 指 
标 单独 计算 其 所 需 的 副本 数 ， 将 所 有 指标 计算 结果 中 的 最 大 值 作为 最 终 
采用 的 副本 数量 。 计 算 时 ， 以 资源 占用 率 为 例 ， 所 有 现 有 Pod 对 象 的 资 
源 占用 率 之 和 除 以 目标 占用 率 所 得 的 结果 即 为 目标 Pod 副 本 数 ， 因 此 增 
加 Pod 副 本 数量 必然 地 会 降低 各 Pod 对 象 的 资源 占用 率 。 


metrics 字 段 值 是 对 象 列表 ， 它 由 要 引用 的 各 指标 的 数据 源 及 其 类 型 


























构成 的 对 象 组 成 。 


-external: 用 于 引用 非 附属 于 任何 对 象 的 全 局 指标 ， 甚 至 可 以 基于 
集群 之 外 的 组 件 的 指标 数据 ， 如 消息 队列 的 长 度 等 。 


object: 引用 描述 集群 中 某 单一 对 象 的 特定 指标 ， 如 Ingress 对 象 上 
的 hits-per-second 等 。 定 义 时 ， 蔡 套 使 用 metricName、target 和 targetValue 
分 别 用 于 指定 引用 的 指标 名 称 、 目 标 对 象 及 指标 的 目标 值 。 


:pods: 引用 当前 被 弹性 伸缩 的 Pod 对 象 的 特定 指标 ， 如 transactions- 
processed-per-second， 各 Pod 对 象 的 指标 数据 取 平 均值 后 与 目标 值 进 
行 比较 。 定 义 时 ， 骸 套 使 用 metricName 和 targetAverageValue 分 别 指定 引 
用 的 指标 名 称 和 目标 平均 值 。 


:resource: 引用 资源 指标 ， 即 当前 被 弹性 伸缩 的 Pod 对 象 中 容器 的 
requests 和 limits 中 定义 的 指标 《CPU 或 内 存 资源 ) 。 定 义 时 ， 购 套 使 用 
name、targetAverageUtilization 和 targetAverageValue 分 别 用 于 指定 资源 的 
名 称 、 目 标 平 均 利 用 率 和 目标 平均 值 。 


-type: 表示 指标 源 的 类 型 ， 其 值 可 为 Objects、Pods 或 Resource。 


基于 自 定义 指标 API 中 的 指标 配置 HPA 对 象 时 ， 其 指标 的 来 源 途 径 
还 包括 pods、object 和 external 等 ， 这 其 中 又 以 Pod 或 引用 的 特定 object 的 
指标 调用 大多。 下面 通过 一 个 示例 来 说 明 其 用 法 ， 并 测试 其 扩 缩 容 的 效 
果 。 


镜像 文件 ikubernetes/metrics- app 在 运行 时 会 局 动 一 个 简单 的 Web 服 
务 器 ， 它 通过 /metrics 路 径 输 出 了 http_requests_total 和 
http_requests_per second 两 个 指 标 。 下 面 是 使 用 此 镜像 文件 创建 的 
Deployment 控 对 | 器 资源 配置 清单 示例 (metrics-app.yaml) ， 它 与 此 前 正 
党 使 用 的 Deployment 资 源 定义 并 无 二 人 至， 除了 特别 附加 的 注解 信息 ， 包 
括 其 中 的 “prometheus.io/scrape: "true"” 是 使 Pod 对 象 能 够 被 Prometheus 采 
集 相 关 指 标的 关键 配置 : 








apiVersion: appSs/VvI 
kind: Deployment 
metadata: 
labels: 
app: metrics-app 
name: metrics-app 


spec: 
replicas: 2 
selector: 
matchLabels: 
app: metrics-app 
template: 
metadata: 
labels: 
app: metrics-app 
annotations: 
prometheus.io/scrape: "true" 
prometheus.io/port: "80" 
prometheus.io/path: "/metrics" 
spec: 
containers: 
- image: ikubernetes/metrics-app 
name: metrics-app 
ports: 
- Name: web 
containerPort: 80 
apiVersion: v1 
kind: Service 


metadata: 
name: metrics-app 
lJabels: 
app: metrics-app 
spec: 
ports: 
- name: web 
port: 80 
targetPort: 80 
selector: 


app: metrics-app 





创建 资源 于 集群 中 ， 启 动 一 个 专用 的 测试 客户 端 Pod， 在 命令 行 中 
向 创建 出 的 Service 端 点 的 /metrics 发 起 访问 请 求 即 可 看 到 它 输出 的 
Prometheus 兼 容 格 式 的 指标 及 数据 : 





~]$ kubectl run client -it --image=cirros --rm -- /bin/sh 

/# curl metrics-app/metrics 

# HELP http_requests total The amount of requests in total 

# TYPE http_requests_ total counter 

http_requests_total 660 

# HELP http_requests per_second The amount of requests per second the latest ten 
seconds 

# TYPE http_requests per_second gauge 

http_requests per_second 0.5 

/ # 








命令 结果 中 返回 了 所 有 的 指标 及 其 数据 ， 每 个 指标 还 附带 了 通过 注 
释 行 提供 的 帮助 (HELP) 信息 和 类 型 (TYPE) 说 明 。Prometheus 通 过 
服务 发 现 机 制 发 现 新 创建 的 Pod 对 象 ， 根 据 注解 提供 的 配置 信息 或 默认 


配置 识别 各 个 指标 并 纳入 采集 对 象 ， 而 后 由 k8s-prometheus-adapter 将 这 
些 指标 注册 到 Kubernetes 的 上 自 定 义 指 标 API 中 ， 提 供给 HPA 〈v2) 控制 器 
和 Kubernetes 调 度 器 等 作为 调度 评估 参数 使 用 。 当 然 ， 用 户 也 可 以 直接 
向 自 定义 指标 API 接 口 发 起 请 求 。 


下 面 的 资源 配置 清单 示例 (metrics-app-hpa.yaml) 用 于 自动 弹性 伸 
缩 前 面 基 于 metrics-app.yaml 创 建 的 metrics-app 相 关 的 Pod 对 象 副本 数 
量 ， 其 伸缩 标准 是 接 入 HITP 请 求 报 文 的 速率 ， 有 具体 的 数据 则 经 由 各 现 
有 相关 Pod 对 象 的 http_requests 指 标的 平均 数据 同 目标 速率 800m《〈 即 0.8 
个 / 秒 ) 的 比较 来 进行 判定 : 








kind: HorizontalPodAutoscaler 
apiVersion: autoscaling/v2beta1i 
metadata: 
name: metrics-app-hpa 
spec: 
scaleTargetRef: 
apiVversion: apps/vi1 
kind: Deployment 
name: metrics-app 
# autoscale between 2 and 10 replicas 
minReplicas: 2 
maxReplicas: 10 
metrics: 
# Use a "Pods" metric, which takes the average of the 
# given metric across all pods controlled by the autoscaling target 
- type: Pods 
pods: 
# USe the metric that you used above: pods/http_requests 
metricName: http_requests 
# target 500 milli-requests per second, 
# which is 1 request every two seconds 
targetAverageValue: 800m 





创建 资源 于 集群 中 ， 而 后 局 动 一 个 测试 客户 端 友 起 持续 性 测试 请 
求 ， 模 拟 压 力 访 问 以 便 其 指标 数据 能 够 满足 扩展 规模 之 需 : 





~]$ kubectl run client -it --image=cirros --rm -- /bin/sh 
/ # while true; do curl http://metrics-app; let i++; Sleep 0.$RANDOM; done 





持续 测试 十 几 分 钟 ， 结 束 后 再 等 上 一 段 时 间 ， 待 平均 请 求 速率 降下 
来 之 后 即 可 通过 HPA 控 制 器 的 详细 信息 了 解 其 规模 变动 状况 ， 然 后 将 会 
得 到 类 似 如 下 规模 变动 的 相关 信息 : 








Events: 


Type Reason Age ”From Message 

Normal SuccessfulRescale 18m horizontal-pod-autoscaler New size: 3; reason: 
pods metric http_requests above target 

Normal SuccessfulRescale 14m horizontal-pod-autoscaler New size: 5; reason: 
pods metric http_requests above target 

Normal SuccessfulRescale 11m horizontal-pod-autoscaler New size: 6; reason: 
pods metric http_requests above target 

Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 5; reason: 
All metrics below target 

Normal SuccessfulRescale 2s horizontal-pod-autoscaler New size: 4; reason: 


All metrics below target 





借助 自 定义 指标 自动 弹性 伸缩 应 用 规模 的 机 制 ， 赋 予 了 不 同 应 用 程 
序 根据 核心 指标 控制 自身 规模 的 能 力 ， 这 是 Kubernetes 系 统 除 敏 捷 部 署 
(Deployment 等 控制 器 ) 功能 之 外 又 一 极 具 特色 的 特性 ， 其 使 得 应 用 运 
维 人 员 从 繁重 的 日 常 监 挖 和 运 维 工作 中 解脱 出 来 。 


14.5 ”本章 小 结 


本 章 介 绍 过 第 一 代 指 标 API 及 其 实现 方案 Heapster 之 后 ， 重 点 介绍 了 
第 二 代 监 控 架 构 体 系 、 资 源 指标 API、 自 定义 指标 API 及 其 各 自 的 解决 
方案 ， 并 对 HPA 及 HPA (v2) 的 使 用 给 予 了 详细 说 明 。 


.指标 API 是 HPA 控 制 器 、Dashboard 和 调度 器 依赖 的 基础 组 件 ， 它 
们 分 别 在 指标 数据 的 基础 上 实现 了 应 用 规模 的 弹性 伸缩 、 指 标 数 据 的 展 
示 和 Pod 对 象 的 调度 。 


Heapster 是 第 一 代 的 指标 API 实 现 方案 ， 也 是 Kubernetes 系 统 曾经 必 
不 可 少 的 核心 附加 组 件 之 一 。 


.新 一 代 监 控 系 统 将 指标 划分 为 核心 指标 和 上 自 定 义 指标 ， 并 把 API 的 
定义 同 其 实现 分 离开 来 。 资 源 指标 API 的 标准 实现 是 Metrics Server， 而 
自 定义 指标 API 的 流行 实现 是 Promethues 及 相应 的 适配器 ， 如 k8s- 
prometheus-adapter。 


.HPA 控 制 器 第 一 代 仅 支持 CPU 指标 数据 ， 而 第 二 代 的 HPA 可 基于 
各 种 核心 指标 和 自 定 义 指 标 实现 应 用 规模 的 自动 变动 。 


第 15 章 ”Helm 程 序 包 管理 器 


业务 的 容器 化 及 微服 务 化 过 程 基本 上 都 是 通过 将 单 体 大 应 用 分 解 为 
多 个 小 的 服务 并 进行 容器 化 编排 运行 来 实现 的 ， 这 种 构建 逻辑 分 解 了 香 
体 应 用 的 复杂 性 ， 让 每 个 微服 务 都 能 够 独立 进行 部 晋 和 扩展 ， 实 现 了 敏 
捷 开 发 和 运 维 。 但 另 一 方面 ， 微 服务 化 拆 解 巨 大 的 单 体 应 用 为 巨 量 的 微 
服务 程序 ， 几 乎 必然 地 导致 了 应 用 管理 复杂 度 的 增加 ， 例 如 ， 在 
Kubernetes 系 统 之 上 ， 每 个 应 用 基本 上 都 有 着 不 止 一 个 资源 ， 而 每 个 应 
用 在 不 同 的 环境 〈 如 qa、test 和 prod 等 ) 中 存在 使 用 不 同 的 配置 参数 的 可 
能 性 等 复杂 问题 。 往 运 的 是 ， 容 器 生态 系统 现在 已 经 发 展 到 了 简便 程 
度 ， 因 为 有 了 Helm。 














15.1 Helm 基 础 


由 前 面 章 节 中 的 应 用 部 晋 过 程 可 知 ， 在 Kubernetes 系 统 上 部 辕 容器 
化 应 用 时 需要 事先 手动 编写 资源 配置 清单 文件 以 定义 资源 对 象 ， 而 且 其 
每 一 次 的 配置 定义 基本 上 都 是 硬 编 码 ， 基 本 上 无 法 实现 复 用 。 对 于 较 大 
规模 的 应 用 场景 ， 应 用 程序 的 配置 、 分 发 、 版 本 控制 、 查 找 、 回 滚 甚 至 
是 查看 都 将 是 用 户 的 置 楚 。Helm 可 大 大 简化 应 用 管理 的 难度 。 


简单 来 说 ，Helm 就 是 Kubernetes 的 应 用 程序 包 管理 器 ， 类 似 于 Linux 
系统 之 上 的 yum 或 apt-get 等 ， 可 用 于 实现 帮助 用 户 碍 找 、 分 享 及 使 用 
Kubernetes 应 用 程序 ， 目 前 的 版 本 由 CNCF (Microsoft、Google、 
Bitnami 和 Helm 社 区 ) 维护 。 它 的 核心 打包 功能 组 件 称 为 chart， 可 以 帮 
助 用 户 创 建 、 安 闭 及 升级 复杂 应 用 。 


Helm 将 Kubernetes 的 资源 〈 如 Deployments、Services 或 ConfigMap 
等 ) 打包 到 一 个 Charts 中 ， 制 作 并 测试 完成 的 各 个 Charts 将 保存 到 Charts 
仓库 进行 存储 和 分 发 。 另 外 ，Helm 实 现 了 可 配置 的 发 布 ， 它 支持 应 用 
配置 的 版 本 管理 ， 简 化 了 Kubernetes 部 署 应 用 的 版 本 控制 、 打 包 、 发 
布 、 删 除 和 更 新 等 操作 。Helm 架 构 组 件 如 图 15-1 所 示 。 
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图 15-1 ” Helm 架构 组 件 


简单 来 说 ，Helm 其 实 就 是 一 个 基于 Kubernetes 的 程序 包 ( 资 源 包 ) 
管理 器 ， 它 将 一 个 应 用 的 相关 资源 组 织 成 为 Charts， 并 通过 Charts 管 理 
程序 包 ， 其 使 用 优势 可 简单 总 结 为 如 下 几 个 方面 : 


-管理 复杂 应 用 : Charts 能 够 描述 哪 介 是 最 复杂 的 程序 结构 ， 其 提供 
了 可 重复 使 用 的 应 用 安装 的 定义 。 


:易于 升级 : 使 用 就 地 升级 和 目 定 义 钩子 来 解决 更 新 的 难题 。 


-简单 分 享 : Charts 易 于 通过 公共 或 私有 服务 完成 版 本 化 、 分 至 及 主 
机 构建 。 


: 回 深 : 可 使 用 “helm rollback” 命 令 轻 松 实现 快速 回 滚 。 





15.1.1 Helm 的 核心 术语 


Helm 将 Kubernetes 应 用 的 相关 配置 组 织 为 Charts， 并 通过 它 完 成 应 
用 的 各 规 管 理 操作 。 通 篆 来 说 ， 使 用 Charts 管 理应 用 的 流程 包括 从 0 开始 
创建 Charts、 将 Charts 及 其 相关 的 文件 打包 为 归档 格式 、 将 Charts 存 储 于 
仓库 〈repository) 中 并 与 之 交互 、 在 Kubernetes 集 群 中 安装 或 凶 载 
Charts 以 及 管理 经 Helm 安 装 的 应 用 的 版 本 发 行 周期 。 因 此 ， 对 Helm 来 
说 ， 它 具有 以 下 几 个 关键 概念 。 


:Charts: 即 一 个 Helm 程 序 包 ， 它 包含 了 运行 一 个 Kubernetes 应 用 所 
需要 的 镜像 、 依 赖 关 系 和 资源 定义 等 ， 必 要 时 还 会 包含 Service 的 定义 ; 
它 类 似 于 APT 的 dpkg 文 件 或 者 yum 的 rpm 文 件 。 


"Repository: Charts 仓 库 ， 用 于 集中 存储 和 分 发 Charts， 类 似 于 Perl 
的 CPAN， 或 者 Python 的 PyPI。 


Config: 应 用 程序 实例 化 安装 运行 时 使 用 的 配置 信息 。 


:Release: 应 用 程序 实例 化 配置 后 运行 于 Kubernetes 集 群 中 的 一 个 
Charts 实 例 ， 在 同一 个 集群 上 ， 一 个 Charts 可 以 使 用 不 同 的 Config 重 复 安 
装 多 次 ， 每 次 安装 都 会 创建 一 个 新 的 Release。 


事实 上 ，Charts 更 像 是 存储 于 Kubernetes 和 集群 之 外 的 程序 ， 它 的 每 次 
安装 是 指 在 集群 中 使 用 专用 配置 运行 一 个 实例 ， 执 行 过 程 有 点 类 似 于 在 
操作 系统 上 基于 程序 启动 一 个 进程 。 








15.1.2 ”Helm 架 构 


Helm 主 要 由 Helm 客 户 端 、Tiller 服 务 器 和 Charts 仓 库 (repository) 
组 成 ， 如 图 15-2 所 示 。 


Helm 客 户 端 是 命令 行 客 户 端 工具 ， 采 用 Go 语言 编写 ， 基 于 gRPC 协 
议 与 Tiller server 交 互 〈 见 图 15-2) 。 它 主要 完成 如 下 任务 。 





Kubernetes Cluster 
Kubernetes Apl Server 


TEER 


gRPC 





图 15-2 ” Helm 成 员 间 通信 
:本 地 Charts 开 发 。 
.管理 Charts 仓 库 。 


.与 Tiller 服 务 器 交互 : 发 送 Charts 以 安装 、 碍 询 Release 的 相关 信息 
以 及 升级 或 番 载 已 有 的 Release。 


Tiller server 是 托管 运行 于 Kubernetes 集 群 之 中 的 容器 化 服务 应 用 ， 
它 接收 来 自 Helm 客 户 端的 请 求 ， 并 在 必要 时 与 Kubernetes API Server 进 





行 交 互 。 它 主要 完成 以 下 任务 。 

.监听 来 自 于 Helm 客 户 端的 请 求 。 

.合并 Charts 和 配置 以 构建 一 个 Release。 

. 回 Kubernetes 集 群 安装 Charts 并 对 相应 的 Release 进 行 跟踪 。 

.升级 和 钊 载 Charts。 

通常 ， 用 户 于 Helm 客 户 端 本 地 遵循 其 格式 编写 Charts 文 件 ， 而 后 即 
可 部 署 于 Kuber-netes 集 群 之 上 运行 为 一 个 特定 的 Release。 仅 在 有 分 发 需 
求 时 ， 才 应 该 将 同一 应 用 的 Charts 文 件 打 包 成 归档 压缩 格式 提交 到 特定 


的 Charts 仓 库 。 仓 库 既 可 以 运行 为 公共 托管 平 侣 ， 也 可 以 是 用 户 目 建 的 
服务 器 ， 仅 供 特 定 的 组 织 或 个 人 使 用 。 





15.1.3 ”安装 Helm Client 


Helm 的 安装 方式 有 两 种 : 预 编译 的 二 进 制程 序 和 源码 编译 安装 。 
这 里 先 介 绍 预 编译 的 二 进 制程 序 的 安装 方式 ， 源 码 编译 安装 的 方式 将 在 
15.1.4 节 的 Tiller 编 译 安装 中 一 并 说 明 。 


Helm 的 每 个 发 行 版 都 提供 了 主流 操作 系统 的 专用 版 本 ， 主 要 包括 
Linux、Mac OS 和 Windows， 用 户 安装 前 按 需 下 载 合 用 的 平台 上 的 相关 
发 行 版 本 即 可 。Helm 项 目 托管 在 GitHub 之 上 ， 项 目地 址 
为 https://github.com/kubernetes/helm 。 


安装 之 前 首先 下 载 合 用 版 本 的 压缩 包 并 将 其 展开 ， 本 示例 中 使 用 的 
是 V2.9.1 的 版 本 。 执 行 具体 命令 时 ， 需 要 丛 换 为 下 载 到 的 版 本 : 











~]$tar-zxvf helm-v2.9.1-linux-amd64.tgz 





而 后 ， 将 其 二 进 制程 序 文件 复制 或 移动 到 系统 PATH 坏 境 变 量 指 问 
2 即 可 ， 如 /usr/localW/bin/ 目 录 〈 管 理 员 用 户 才 有 写 入 文件 至 此 日 
录 的 权限 〉: 





~]$sudo mv linux-amd64/helm/usr/local/bin/ 





Helm 的 各 种 管理 功能 均 可 通过 其 子 命令 完成 ， 获 取 其 使 用 帮助 ， 
直接 使 用 “help* 子 命令 即 可 : 


~]$helm help 


需要 注音 的 是 ，Helm 的 运行 依赖 于 本 地 安装 并 配置 完成 的 kubectl 方 
能 与 运行 于 Kubernetes 集 群 之 上 的 Tiller 服 务 器 进行 通信 ， 因 此 ， 运 行 
Helm 的 节点 也 应 该 是 可 以 正常 使 用 kubectl 命 令 的 主机 ， 或 者 至 少 是 有 着 
可 用 kubeconfig 配 置 文件 的 主机 。Mac OS 或 Windows 系 统 上 的 安装 方式 
请 参考 Helm 官 方 文档 。 


15.1.4 ”安装 Tiller server 


Tiller 是 Helm 的 服务 絮 病 ， 一 般 应 该 运行 于 Kubernetes 集 群 之 上 ， 不 
过 ， 出 于 研发 使 用 的 目的 ， 也 可 以 将 其 部 车 于 本 地 ， 且 需要 能 够 与 远程 
Kubernetes 集 群 正常 通信 ， 这 里 选择 将 其 托管 运行 于 集群 之 上 。 男 外 ， 
对 于 了 RBAC 授 权 插 件 的 Kubernetes 集 群 来 说 ， 还 需要 事先 创建 相关 的 
ServiceAccount 才 能 进行 安装 。 


下 面 的 资源 配置 清单 示例 中 (tiller-rbac.yaml〉 定 义 了 一 个 名 为 tiller 
的 ServiceAccount， 并 通过 ClusterRoleBinding 将 其 绑 定 至 集群 管理 员 角 
色 cluster-admin， 从 而 使 得 它 拥有 集群 级 别 所 有 的 最 高 权限 : 











apiVersion: v1 
kind: ServiceAccount 
metadata: 
name: tiller 
namespace: kube-system 


apiVersion: rbac.authorization.k8s.io/vibetal 
kind: ClusterRoleBinding 
metadata: 
name: tiller 
roleRef: 
apiGroup: rbac.authorization.k8s.io 
kind: ClusterRole 
name: cluster-admin 
subjects: 
- kind: ServiceAccount 
name: tiller 
namespace: kube-system 





将 上 面 清 单 的 内 容 保 存 于 文件 中 ， 如 tiller-rbac.yaml， 而 后 执行 命令 
以 完成 绑 定 : 





~]$ kubectl1 apply -f tiller-rbac.yaml 
serviceaccount "tiller" created 
clusterrolebinding.rbac.authorization.k8s.io "tiller" created 





而 后 使 用 如 下 命令 进行 Tiller server 环 境 的 初始 化 ， 完 成 Tiller server 
安装 : 





~]$ helm init --service-account tiller 





© 注意 ”helm init 命 令 进行 初始 化 时 ，Kuberntes 集 群 会 到 
gcr.io/kubernetes-helm/ 上 获取 需要 的 镜像 ， 镜 像 标签 同 Helm 的 版 本 号 。 
请 确保 Kubernetes 集 群 能 够 正确 访问 此 镜像 仓库 。 


若 有 必要 ， 可 以 基于 SSL/TLS 实 现 Helm 和 Tiller 之 间 的 通信 ， 这 就 
需要 在 部 署 Tiller 时 为 其 指定 专用 的 选项 --tiller-tls-verify， 并 为 后 续 的 所 
有 Helm 命 令 额外 附加 --tds 选 项 。 部 署 完成 后 可 使 用 “kubectl get pods” 命 
令 确 认 Tiller Pod 运 行 正常 ， 如 下 面 的 命令 所 示 : 








~]$ kubectl1 get pods -n kube-system -1 app=helm 
NAME READY STATUS RESTARTS AGE 
tiller-deploy-5c688d5f9b-gt65w 1/1 Running 0 4m 





安装 完成 后 ， 运 行 中 elm version” 命 令 即 可 显示 客户 端 和 服务 端的 版 
本 号 ， 奉 两 者 均 显 示 正 常 ， 则 表示 安装 成 功 。 到 此 为 止 ， 运 行 于 
Kubernetes 集 群 中 的 Tiller Server 已 经 配置 完成 ， 管 理 员 可 按 需 实现 后 续 
的 其 他 管理 工作 ， 人 例如， 搜索 可 用 的 Charts， 安 装 Charts 到 集群 中 等 。 


如 果 和 希望 在 安装 时 自 定 义 一 些 参数 以 设 定 其 运行 机 制 ， 例 如 Tiller 
的 版 本 或 者 在 Kubernetes 集 群 上 的 目标 名 称 空间 ， 则 可 以 以 类 似 如 下 方 
式 使 用 命令 : 

.--canary-image: 安装 canary 分 支 ， 即 项 目 Master 的 分 支 。 

-tiller-image: 安装 指定 版 本 的 镜像 ， 默 认同 Helm 版 本 。 


.--kube-context: 安装 至 指定 的 Kubernetes 集 和 群 。 








--tiller-namespace: 安装 至 指定 的 名 称 空间 ， 默 认为 kube-system 。 

此 外 ，Tiller 将 数据 存储 于 ConfigMap 资 源 中 ， 因 此 印 载 后 重新 安装 
并 不 会 导致 数据 丢失 ， 必 要 时 ， 管 理 员 尽 可 放心 重新 安装 或 升级 。 外 载 
Tiller 的 方法 第 用 的 有 两 种 方式 。 


1) kubectl delete deployment tiller-deploy--namespace kube-system 


2) helm reset 


至 此 ，Helm 和 Tiller 的 安装 设 定 工作 已 经 完成 ， 接 下 来 便 可 尝试 使 
用 Helm 市 来 的 诸多 便捷 之 处 。 


15.1.5 Helm 快 速 入 门 


Charts 是 Helm 的 程序 包 ， 它 们 存储 于 Charts 仓 库 中 。Kubernetes 官 方 
的 Charts 仓 库 保存 了 一 系列 精心 制作 和 维护 的 Charts， 仓 库 的 默认 名 称 
为 “stable”。 安 装 Charts 到 Kubermetes 集 群 时 ，Helm 首 先 会 到 Kubernetes 官 
方 的 Charts 仓 库 中 获取 到 相关 的 Charts， 而 后 将 其 安装 并 创建 为 


Release。 





@ 提示 “Helm 的 官方 仓库 为 https://kubernetes- 
charts.storage.googleapis.com ， 进 行 后 续 的 操作 之 前 请 确保 拥有 访问 此 
站 点 的 能 力 。 


“helo repo” 相 关 的 命令 可 用 于 管理 使 用 的 Charts 仓 库 ， 其 update 子 命 
令 能 够 更 新 使 用 的 默认 仓库 的 元 数据 信息 ， 其 命令 及 执行 结果 如 下 所 
个 \: 


~ 





~]$ helm repo update 

Hang tight while we grab the latest from your chart repositories... 
,. .Skip local chart repository 

...Successfully got an update from the "stable" chart repository 
Update Complete. * Happy Helming! * 





“helm search” 命 令 可 列 出 stable 仓 库 中 维护 的 所 有 Charts 的 列表 ， 如 
下 面 命令 结果 中 列 出 的 部 分 Charts: 





~]$ helm search 


NAME CHART VERSION APP VERSION DESCRIPTION 

stable/coredns 0.9.0 1.0.6 CoreDNS is a DNS server that 
chains plugins and... 

stable/docker-registry 1.4.0 2.6.2 A Helm chart for Docker Registry 

stable/etcd-operator 0.7.7 0.7.0 CoreoS etcd-operator Helm chart 
for Kubernetes 

stable/gitlab-ce 0.2.1 GitLab Community Edition 

stable/grafana 1.9.0 5.1.2 The leading tool for querying 
and visualizing tt... 

stable/jenkins 0.16.1 2.107 Open source continuous inte- 
gration server. It Ss.,.. 

stable/kubernetes-dashboard 0.6.8 1.8.3 General-purpose web UI for Kub- 
ernetes clusters 

stable/mysql 0.5.0 5.7.14 Fast, reliable, scalable, and 


easy to useopen-... 





也 可 以 为 search 命 令 谎 加 一 个 过 滤器 ， 仅 列 出 符合 条 件 的 Charts， 例 
如 下 面 的 命令 以 redis 为 过 滤 条 件 ， 仅 显示 与 redis 相 关 的 所 有 Charts: 





~]$ helm search redis 


NAME CHART VERSION APP VERSION DESCRIPTION 

stable/prometheus-redis-exporter 0.1.1 0.16.0 Prometheus exporter for Redis 
metrics 

stable/redis 3.3.0 4.0.9 Open source, advanced key- 


value store. It is of... 





“helm inspect” 命 令 能 够 打印 出 指定 的 Charts 的 详细 信息 : 





~]$ helm inspect stable/redis 

appVersion: 4.0.9 

description: Open source, advanced key-value store. It is often referred to as a dat 
structure server since keys can contain strings, hashes, lists, sets and sorted 
Sets ， 





安装 指定 的 Charts 为 Kubernetes 集 和 群 的 Release， 可 使 用 “helm 
install” 命 令 进 行 ， 例 如 和 若 需 要 安装 stable/redis， 则 为 命令 行使 用 -nn 选项 
指定 Release 名 称 即 可 。 当 然 ， 也 可 以 先 执行 安 装 测试 ， 例 如 : 





~]$ helm install stable/redis -n redis --dry-run 
NAME : redis 








若 无 错误 信息 返回 ， 则 移 除 --dry-run 选 项 即 可 进入 安装 流程 ， 命 令 
会 返回 安装 过 程 的 执行 步骤 ， 以 及 最 后 的 注意 信息 ， 它 们 通 间 是 应 用 的 
使 用 帮助 ， 因 此 是 需要 特别 注意 的 内 容 : 











~]$ helm install stable/redis -n redis 
NAME : redis 

LAST DEPLOYED: Thu May 17 13:10:11 2018 
NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> v1i/Secret 

NAME TYPE DATA AGE 
redis Opaque 1 0S 


==> v1/Service 


NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
redis-master ClusterIP 10.105.63.22 <none> 6379/TCP 0s 
redis-slave ClusterIP 10.105.114.60 <none> 6379/TCP 0s 
NOTES : 


** Please be patient while the chart is being deployed ** 
Redis can be accessed via port 6379 on the following DNS names from within your 
cluster: 


redis-master.default,.svc.cluster.local for read/write operations 
redis-slave.default,.svc.cluster.local for read-only operations 





多 数 应 用 的 Charts 都 可 以 接受 用 户 提 供 的 配置 参数 进行 特定 的 场景 
化 部 署 ， 所 有 可 配置 参数 都 会 通过 Charts 模 板 提 供 ， 用 户 把 需要 提供 参 
的 配置 选项 存储 在 YAML 格 式 的 配置 文件 中 并 通过 -f 命 令 行 选项 加 
载 即 可 。 


若 要 列 出 已 经 安装 生成 的 Release， 则 需要 使 用 “helm list”* 命 令 : 





~]$ helm list 
NAME REVISION UPDATED STATUS CHART NAMESPACE 
redis 1 Thu May 17 13:10:11 2018 DEPLOYED redis-3.3.0 default 





而 要 删除 Release， 则 使 用 “helm delete” 命 令 即 可 。 





~]$ helm delete redis 
release "redis" deleted 





升级 或 回 深 应 用 ， 要 分 别 使 用 “helm upgrade” 和 “helm rollback” 命 
令 ， 而 且 还 可 以 使 用 “helm history” 命 令 获取 指定 的 Release 变 更 的 历史 。 
不 过 ， 寿 默认 仓库 中 不 存在 所 需要 的 某 Charts， 而 对 用 户 来 说 该 Charts 
是 日 党 部 敬 任 务 ， 则 用 户 可 以 自行 编写 Charts 并 分 享 。 事实 上 ，helm 
install 命 令 文 持 基于 多 种 安装 源 进行 应 用 部 车 ， 这 包括 Charts 仓 库 、 本 地 
的 Charts 压 缩 包 、 本 地 Charts 目 录 ， 甚 至 是 指定 某 个 Charts 的 URL。 











15.2 Helm Charts 


Charts 是 Helm 使 用 的 Kubernetes 程 序 包 打包 格式 ， 一 个 Charts 就 是 一 
个 描述 一 组 Kubernetes 资 源 的 文件 的 集合 。 事 实 上 ， 一 个 单独 的 Charts 既 
能 用 于 部 署 简 单 应 用 ， 例 如 一 个 memcached Pod， 也 能 部 署 复杂 的 应 
用 ， 如 由 HTTP 服 务 器 、DB 服 务 器 、Cache 服 务 器 和 应 用 程序 服务 器 等 
共同 组 成 的 Web 应 用 栈 。 


从 物理 的 角度 来 描述 ，Charts 是 一 个 章 循 特定 规范 的 目录 结构 ， 它 
能 够 打包 成 为 一 个 可 用 于 部 署 的 版 本 化 归档 文件 。 


15.2.1 ”Charts 文 件 组 织 结构 


一 个 Charts 就 是 按 特 定格 式 组 织 的 目录 结构 ， 目 录 名 即 为 Charts 
名 ， 目 录 名 称 本 身 不 包含 版 本 信息 。 例 如 ， 一 个 jenkins Charts 的 目录 结 
构 应 该 如 下 所 示 : 





jenkins/ 
Chart .yaml 
LICENSE 
README .md 
requirements.yaml 
values.yaml 
charts/ 
templates/ 
templates/NOTES. txt 





目录 结构 中 除了 charts/ 和 templates/ 是 目录 之 外 ， 其 他 的 都 是 文件 。 
它们 的 基本 功用 如 下 。 


Chart.yaml: 当前 Charts 的 描述 信息 ，yaml 格 式 的 文件 。 


:LICENSE: 当前 Charts 的 许可 证 信息 ， 纯 文本 文件 ， 此 为 可 选 文 
件 。 


README.md: 易 读 格式 的 README 文 件 ， 可 选 。 
requirements.yaml: 当前 Charts 的 依赖 关系 描述 文件 ， 可 选 。 
-Values.yaml: 当前 Charts 用 到 的 默认 配置 值 。 

:charts/， 目 录 ， 存 放 当 前 Charts 依 赖 到 的 所 有 Charts 文 件 。 


:templates/; 目录 ， 存 放 当 前 Charts 用 到 的 模板 文件 ， 可 应 用 于 
Charts 生 成 有 效 的 Kuber-netes 清 单 文 件 。 


templates/INOTES.txt: 纯 文 本 文件 ，Templates 简 单 使 用 注解 。 


尽管 Charts 和 Templates 目 录 均 为 可 选 ， 但 至 少 应 该 存在 一 个 Charts 
依赖 文件 或 一 个 模板 文件 。 另 外 ，Helm 保 留 使 用 charts/ 和 templates/ 目 录 


以 及 上 面 列 出 的 文件 名 称 ， 其 他 文件 都 将 被 忽略 。 


15.2.2 ”Chart.yaml 文 件 组 织 格式 


Chart.yaml 用 于 提供 Charts 相 关 的 各 种 元 数据 ， 如 名 称 、 版 本 、 关 键 
词 、 维 护 者 信息 、 使 用 的 模板 引擎 等 ， 它 是 一 个 Charts 必 备 的 核心 文 
件 ， 主 要 包含 以 下 字段 。 


name: 当前 Charts 的 名 称 ， 必 选 字 段 。 





.Version: 遵循 语义 化 版 本 规范 第 2 版 的 版 本 号 ， 必 选 字段 。 
:description: 当前 项 目的 单 语句 描述 信息 ， 可 选 字段 。 
keywords: 当前 项 目的 关键 词 列 表 ， 可 选 字段 。 


-home: 当前 项 目的 主页 UREL， 可 选 字 段 。 





sources: 当前 项 目 用 到 的 源码 的 来 源 UREL 列 表 ， 可 选 字段 。 





:maintainers: 项 目 维护 者 信息 ， 主 要 机 套 name、email 和 URL 几 个 
属性 组 成 ， 可 选 字 上 段 。 


“engine: 模板 引擎 的 名 称 ， 默 认为 gotpl， 即 go 模板 。 


"icon: UREL， 指 向 当前 项 目的 图 标 ，SVG 或 PNG 格 式 的 图 片 ， 可 选 
字段 。 


:appVersion: 本 项 目 用 到 的 应 用 程序 的 版 本 号 ， 可 选 字段 ， 且 不 必 
为 语义 化 版 本 。 





deprecated: 当前 Charts 是 否 已 废弃 ， 可 选 字 段 ， 布 尔 型 值 。 


tillerVersion: 当前 Charts 依 赖 的 Tiller 版 本 号 ， 可 以 是 语义 化 版 本 
号 的 范围 ， 如 “>2.4.0”， 可 选 字 上 段 。 


例如 ， 下 面 的 示例 信息 是 rediss Charts 中 使 用 的 Chart.yaml 的 内 容 ， 
用 户 目 行 定义 Charts 编 写 相 关 文 件 时 ， 要 采用 类 似 的 文件 格式 : 


appVersion: 4.0.9 

description: Open source, advanced key-value store. It is often referred 
to as a data structure server since keys can contain strings, hashes, 
lists, sets and sorted sets. 

engine: gotpl 

home: http://redis.io/ 

icon: https://bitnami,.com/assets/stacks/redis/img/redis-stack-220x234.png 

keywords: 

- redis 

- keyvalue 

- database 

maintainers: 

- email: containers@bitnami.com 
name: bitnami-bot 

name: redis 

sources: 

- https://github.com/bitnami/bitnami-docker-redis 

version: 3.3.0 


4 


15.2.3 ”Charts 中 的 依赖 关系 


Helm 中 的 一 个 Charts 可 能 会 依赖 不 止 一 个 其 他 的 Charts， 这 种 依赖 
关系 可 经 requirements.yaml 进 行动 态 链接 ， 也 可 直接 存储 于 charts/ 目 录 中 
进行 手动 管理 。 不 过 ， 尽 管 手 动 管理 依赖 关系 对 个 别管 理 场景 也 有 着 些 
许 优 势 ， 但 使 用 动态 管理 的 方式 却 是 推荐 的 首选 方式 。 








1.requirements.yaml 文 件 


requirements.yaml 文 件 本 质 上 只 是 一 个 简单 的 依赖 关系 列表 ， 它 具 
有 类 似 如 下 定义 中 的 格式 中 的 可 用 字段 : 


dependencies: 


version: 

repository: 

alias: 

tags: 

condition: 

import-values: 
- child: 

parent: 





上 述 示例 中 的 字段 基本 可 以 见 名 知 义 ， 具 体 如 下 。 
name: 被 依赖 的 Charts 的 名 称 。 
.version: 被 依赖 的 Charts 的 版 本 。 


Tepository: 被 依赖 的 Charts 所 属 的 仓库 及 其 URL;， 如 果 是 非 官方 的 
仓库 ， 则 需要 先 用 helm repo add 命 令 将 其 添加 进 本 地 可 用 仓库 。 


“alias: 为 被 依赖 的 Charts 创 建 一 个 别名 ， 从 而 让 当前 Charts 可 以 将 
所 依赖 的 Charts 对 应 到 新 名 称 ， 即 别名 ; 可 选 字 段 。 


tags: 默认 情况 下 所 有 的 Charts 都 会 被 装载 ， 辱 给 定 了 tags， 则 仪 装 
载 那 些 匹 配 到 的 Charts。 


condition: 类 似 于 tags 字 段 ， 但 雷 要 通过 自 定义 的 条 件 来 指明 要 类 





载 的 charts 。 


"import-values: 导入 子 Charts 中 的 的 值 ， 被 导入 的 值 需要 在 子 charts 
中 导出 。 


如 下 所 示 的 示例 ， 是 Wordpress Charts 中 定义 的 动态 依赖 关系 : 








dependencies: 
- name: mariadb 
version: 2.1.1 
repository: https://kubernetes-charts,.storage.googleapis.com/ 
condition: mariadb.enabled 
tags: 
- wordpress-database 





一 旦 依赖 关系 文件 配置 完成 ， 即 可 使 用 “helm dependency update” 命 
令 更 新 依赖 关系 ， 并 自动 下 载 被 依赖 的 Charts 至 charts/ 目 录 中 。 


2.Charts 目 录 


行 需 要 对 依赖 关系 进行 更 多 的 控制 ， 则 所 有 被 依赖 到 的 Charts 都 能 
以 手工 方式 直接 复制 到 Charts 目 录 中 。 一 个 被 依赖 到 的 Charts 既 可 以 是 
归档 格式 ， 也 可 以 是 展开 的 目录 格式 ， 不 过 ， 其 名 称 不 能 以 下 划 线 
(_) 或 点 号 〈.) 开头 ， 此 类 文件 会 被 Charts 疙 载 器 上 自动 忽略 。 


例如 ，Wordpress Charts 依 赖 关 系 在 其 Charts 目 录 中 的 反映 类 似 如 下 
所 示 : 





charts/ 

-一 mariadb 

FF 一 Chart ,yam1 

FF 一 README.md 

FF 一 templates 

| 一 configmap.yaml 

[一 deployment .yaml 
_helpers.tpl 

me NOTES. txt 

| 一 pvc.yaml 

| 一 secrets .yam1 


svc.yaml 
test-runner.yaml 


[一 tests.yaml 
— values.yaml 








15.2.4 ”模板 和 值 


Helm Charts 模 板 〈template) 遵循 Go 模板 语言 格式 ， 并 文 持 50 种 以 
上 的 来 自 Spring 库 的 模板 函数 附件 ， 以 及 为 数 不 少 的 其 他 专用 函数 。 所 
有 的 模板 文件 都 存储 于 Templates 目 录 中 ， 在 当前 Charts 被 Helm 引 用 时 ， 
此 目录 中 的 所 有 模板 文件 都 会 传递 给 模板 引擎 进行 处 理 。 

模板 文件 中 用 到 的 值 (value) 有 如 下 两 种 提供 方式 。 

:通过 Charts 的 values.yaml 文 件 提供 ， 通 常用 于 提供 默认 值 。 


-在 运行 “helm install” 命 令 时 传递 包含 所 需要 的 目 定义 值 的 YAML 文 
件 ， 此 处 传递 的 值 会 覆 凋 默认 值 。 


下 面 的 示例 是 Wordpress Charts 中 Deployment 模 板 文件 的 部 分 内 容 : 








apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
name: {{ template "fullname" . }} 
labels: 
app: {{ template "fullname" . }} 
chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" 
release: "{{ .Release.Name }}" 
heritage: "{{ .Release.Service }}" 
spec: 
replicas: 1 
template: 
metadata: 
labels: 
app: {{ template "fullname" . }} 
spec: 
containers: 
- name: {{ template "fullname" . }} 
image: "{{ .Values.image }}" 
imagePullPolicy: {{ default "" .Values.imagePullPolicy | quote }} 





示例 中 模板 相关 的 代码 部 分 会 由 模板 引擎 运行 ， 并 生成 相应 的 结 
果 。 供 依赖 的 值 可 由 values.yaml 文 件 或 由 用 户 在 运行 helm install 命 令 时 
通过 选项 提供 ， 除 此 之 外 ，char 模 板 还 包含 一 些 固 定 的 预定 义 值 ， 如 
Release.Name、 Release.Time、Release.Time、Release.Service、 
Release.IsUpgrade 、Release.IsInstall、Release.Revision、Chart.Name、 





Chart.Version、Files 和 Capabilities 等 。 


而 在 values.yaml 一 类 的 文件 中 定义 值 (value〉 时 ， 既 可 以 将 它们 定 
义 为 全 局 作用 域 ， 也 可 以 定义 为 仅 供 Charts 目 录 下 的 某 个 Charts 所 使 
用 。 一 般 来 说 ， 上 级 Charts 可 访问 下 级 Charts 中 的 值 ， 但 下 级 Charts 不 能 
访问 其 上 级 Charts 的 值 。 


如 下 面 示例 中 的 内 容 ， 其 中 title 属 于 全 局 作用 域 ，max_connections 
和 password 则 仅 属 于 mysql Charts，port 仅 属于 apache Charts: 








title: "My WordPress Site" # Sent to the WordPress template 


mysql: 
max_connections: 100 # Sent to MySQL 
password: "secret" 


apache : 
port: 8080 # Passed to Apache 





Go 模板 语法 请 参考 godoc 站 点 中 的 内 容 ， 地 址 
为 https://godoc.org/text/template 。 


15.2.5 ”其 他 需要 说 明 的 话题 


定义 Charts 时 还 需要 用 到 许可 证 文件 (License) 、 自 述 文 件 
(README.md) 以 及 说 明文 件 (NOTE.txt) ， 其 中 说 明文 件 需 要 为 用 
户 提供 重要 的 使 用 帮助 及 注意 事项 等 。 基于 Charts 的 格式 规范 ， 用 户 即 
可 自 定 义 相关 应 用 程序 的 Charts， 并 将 其 通 是 过 仓库 完成 分 享 。 


Charts 中 也 支持 使 用 文件 来 描述 安装 、 配 置 、 0 
一 般 说 来 ，README 文 件 必 须 为 Markdown 格 式 ， 因 此 其 后 级 名 通 
是 “md”， 它 一 般 应 该 包含 如 下 内 容 。 

当前 Charts 提 供 的 应 用 或 服务 的 描述 信息 。 

:运行 当前 Charts 需 要 满足 的 条 件 。 

Values.yaml 文 件 中 选项 及 默认 值 的 描述 

:其 他 任何 有 助 于 安装 或 配置 当前 Charts 的 有 用 信息 。 

另外 ，templatesNOTES.txt 文 件 中 的 内 容 将 会 在 Charts 安 装 完 成 后 
予以 输出 ， 通 品 用 于 同 用 户 提 供 当 前 Charts 相 关 的 使 用 或 急 始 访问 方式 


的 信息 。 男 外 ， 使 用 “helm status” 命 令 查 看 某 Release 的 相关 状态 信息 
时 ， 此 文件 中 的 内 容 也 会 输出 。 





15.2.6” 目 定义 Charts 


一 个 典型 的 服务 类 容器 化 应 用 通常 会 由 Pod 控 制 嚣 (常用 的 为 
Deployment) 、Service、ConfigMap、Secret、Ingress 和 
PersistentVolumeClaim 等 资源 对 象 组 成 ， 其 中 前 两 者 基本 上 是 必 备 的 资 
源 ， 后 面 三 个 则 可 按 需 进行 定义 。Helm Charts 包 含 了 这 些 组 件 的 yaml 格 
式 的 资源 配置 文件 模板 ， 它 们 能 够 通过 values.yaml 配 置 文件 获取 模板 中 
的 各 个 变量 所 需 的 “ 值 >， 甚 至 文 持 用 户 在 部 署 操 作 的 运行 时 进行 配置 。 


1. 生 成 一 个 空 Charts 
创建 一 个 新 Charts 的 有 效 方式 是 使 用 “helm create” 命 令 ， 它 能 够 在 新 


目录 中 创建 一 个 名 为 mychart 的 新 图 表 。 例 如 ， 下 面 的 命令 会 于 命令 执 
行 的 当前 目录 中 创建 一 个 名 为 mychart 的 子 目 录 作 为 Charts 存 储 路 径 : 








~]$ helm create mychart 
Creating mychart 








此 命令 会 初始 化 出 一 个 空 的 Charts 目 录 结 构 ， 它 有 着 所 需要 的 各 个 
核心 文件 : 





~]$ tree mychart/ 
mychart/ 


| 一 charts 
| 一 chart.yaml 


templates 
而 | 一 deployment .yaml 
| | 一 _helpers.tpl 
| | 一 ingress.yaml 
NOTES ,七 Xt 
| service.yaml 
[一 values.yaml 








由 命令 生成 的 各 文件 还 有 着 各 自 应 该 具有 的 通用 组 织 结构 框架 ， 例 
如 ，Chart.yaml 文 件 的 默认 内 容 如 下 : 








apiVersion: v1 
appVersion: "1.0" 
description: A Helm chart for Kubernetes 


name: mychart 
version: 0.1.0 








事实 上 ， 它 甚至 直接 在 values.yaml 将 要 使 用 的 镜像 文件 定义 中 为 
nginx 和 生成 了 一 个 可 直接 安装 容 右 化 Nginx 应 用 的 Charts， 其 中 的 部 分 内 
容 如 下 所 示 : 








replicaCount: 1 


image: 
repository: nginx 
tag: stable 
pullPolicy: IfNotPresent 


service: 
type: ClusterIP 
port: 80 

















因此 ， 用 户 仅 需要 在 各 文件 现 有 框架 的 基础 上 按 需 进行 修改 即 可 定 
义 出 所 需 的 Charts 来 。 


2. 修 改 Charts 以 部 署 自 定 义 服务 


这 里 以 此 前 使 用 的 容器 应 用 “ikubernetes/myapp: V1” 为 示例 来 说 明 
如 何 定义 一 个 Charts。 使 用 “helm create” 命 令 生 成 的 Charts 会 创建 一 个 用 
于 运行 、 由 默认 值 提 供 的 镜像 的 Deployment 对 象 ， 这 就 意味 着 若 要 部 署 
不 同 的 应 用 仅 通 过 修改 values.yaml 中 的 引用 镜像 文件 即 可 。 当 然 ， 必 要 
时 ， 用 户 还 需要 额外 确认 是 人 否 需要 默认 的 mgress 对 象 的 定义 ， 以 及 需要 
额外 用 到 存储 资源 。 


例如 ， 这 里 将 values.yaml 文 件 的 内 容 修改 为 如 下 所 示 : 











repository: ikubernetes/myapp 
tag: vi 
pullPolicy: IfNotPresent 


service: 
type: ClusterIP 
port: 80 


ingress: 
enabled: false 
annotations: {} 
# kubernetes.io/ingress.class: nginx 
# kubernetes.io/tls-acme: "true" 


path: / 
hosts : 
- chart-example.local 
tls: [] 
# - secretName: chart-example-tls 
# hosts: 
# - chart-example.1local 


resources: 
limits: 
cpu: 500m 
memory: S512Mi 
requests: 
cpu: 500m 
memory: S512Mi 


nodeSelector: {} 
tolerations: [] 


affinity: {} 





而 后 通过 “helm lint” 命 令 确 认 修改 后 的 Charts 是 否 遵循 最 佳 实践 且 模 
板 格式 民 好 : 





~]$ helm lint mychart 
==> Linting mychart 
[INFO] Chart.yaml: Icon is recommended 


1 chart(s) linted, no failures 











多 数 情况 下 ，“helm lint* 命 令 报告 的 错误 信息 ， 根 据 其 错误 提示 中 
的 行 写 信息 即 能 定位 出 错误 所 在 。 确 保 一 切 问 题 都 得 以 解决 之 后 ， 即 可 
通过 “helm install” 命 令 调 试 运行 以 查看 由 Charts 定 义 的 容器 化 应 用 是 否 能 
够 正确 部 署 : 





~]$ helm install --name myapp --dry-run --debug ./mychart --set service.type= 
NodePort 
[debug] Created tunnel using local port: "40255 


[debug] SERVER: "127.0.0.1:40255" 
[debug] Original chart version: "™" 
[debug] CHART PATH: /home/ik8s/charts/mychart 


NAME: myapp 

REVISION: 1 

RELEASED: Tue Jun 5 16:14:45 2018 
CHART: mychart-0.1.0 

USER-SUPPLIED VALUES : 

service: 


type: NodePort 





确认 上 述 命 令 输 出 信息 无 误 后 ， 移 除 命 令 中 的 “--dry-run” 选 项 后 再 
次 运行 命令 即 可 完成 应 用 的 部 署 : 





~]$ helm install --name myapp ./mychart --set Service.type=NodePort 
NAME : myapp 

LAST DEPLOYED: Tue Jun 5 16:20:22 2018 

NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> v1i/Service 

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
myapp-mychart NodePort 10.108.65.88 <none> 80:30315/TCP 1s 
==> v1i/Deployment 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
myapp-mychart 1 1 1 0 0S 

==> v1i/Pod(related) 

NAME READY STATUS RESTARTS AGE 
myapp-mychart-67b9997c8b-nbsfk 0/1 ContainerCreating 0 Os 
NOTES: 


1. Get the application URL by running these commands : 
export NODE PORT=$(kubectl] get --namespace default -0 jsonpath="{.spec.ports 
[0] .nodePort}" services myapp-mychart) 
export NODE_ IP=$(kubectl1 get nodes --namespace default -o jsonpath="{.items[0]. 
status.addresses[0].address}") 
echo http://$NODE_IP: $NODE_PORT 





而 后 ， 通 过 上 述 NOTES 中 的 命令 提示 运行 相关 的 命令 获取 访问 端 
太后 即 可 通过 浏览 器 访问 相应 的 服务 : 





~]$ export NODE_PORT=$(kubectl] get --namespace default -oO \ 
jsonpath="{.spec.ports[0].nodePort}" services myapp-mychart) 
~]$ export NODE_IP=$(kubectl get nodes --namespace default -o \ 

jsonpath="{.items[0].status.addresses[0].address}") 

~]$ echo http://$NODE_IP: $NODE_ PORT 

http://172.16.0.70:30376 





而 后 通过 浏览 器 访问 测试 所 部 署 的 myapp 应 用 。 
3.Charts 仓 库 (Repository) 
至 此 ， 一 个 自 定义 的 Charts 即 于 本 地 设 定 完 成 ， 不 过 ， 它 仪 能 用 于 


本 地 访问 。 当 然 ， 用 户 也 可 以 通过 “helm package” 命 令 将 其 打包 为 tar 格 
式 后 分 享 给 团队 或 者 社区 : 





~]$ helm package ./mychart 
Successfully packaged chart and saved it to: /root/charts/mychart-0.1.0.tgz 





Helm 将 在 工作 目录 中 创建 一 个 mychart-0.1.0.tgz 包 ， 它 使 用 
Chart.yaml 文 件 中 定义 的 元 数据 的 名 称 和 版 本 。 通 过 将 程序 包 作 为 参数 
传递 给 helm install， 用 户 可 以 基于 该 程序 包 而 不 是 本 地 目录 进行 安装 : 








~]$ helm install --name myapp2 mychart-0.1.0.tgz --set service.type=NodePort 











为 了 使 软件 包 更 容易 分 享 ，Helm 内 置 了 从 HTTP 服 务 器 安装 软件 包 
的 支持 。 运 行 时 ，Helm 读 取 服 务 器 上 托管 的 仓库 索引 ， 该 索引 摘 述 了 
有 哪些 Charts 程 序 包 可 用 以 及 它们 位 于 何 处 。 使 用 “helm serve” 命 令 即 可 
运行 本 地 仓库 来 输出 本 地 创建 的 Charts: 





~]$ helm serve 
Regenerating index. This may take a moment. 
Now serving you on 127.0.0.1:8879 





此 命令 会 占据 当前 终端 ， 于 是 ， 男 启 一 个 终端 即 可 测试 访问 本 地 仓 
库 服务 中 的 Charts: 





~]$ helm search local 
NAME CHART VERSION APP VERSION DESCRIPTION 
local/mychart 0.1.0 1.0 A Helm chart for Kubernetes 





尽管 Helm 能 够 管理 本 地 仓库 ， 但 创建 好 的 Charts 如 需 同 外 分 享 ， 就 

要 为 其 创建 用 于 共享 的 仓库 ， 并 将 计划 共享 的 所 有 Charts 都 放置 于 仓 
事实 上 ，Charts 仓 库 服 务 器 束 是 HTTP 服 务 器 ， 任 何 能 支持 YAML 
文件 及 tar 文 件 传 输 的 HTTP 服 务 器 程序 都 可 以 作为 仓库 服务 器 使 用 。 不 
过 ， 一 般 来 说 ， 一 个 仓库 应 该 有 一 个 index.html 主 页 用 于 摘 述 当前 仓库 
中 的 所 有 Charts 及 其 元 数据 信息 。 然 而 ， 到 目前 为 止 ，Helm 并 不 文 持 将 
Charts 上 传 至 仓库 中 ， 因 为 这 样 做 会 对 仓库 服务 器 程序 多 出 很 多 额外 的 
要 求 ， 并 且 也 会 增加 其 配置 的 复杂 度 。 这 就 意味 着 ， 上 传 Charts 到 仓库 





中 需要 借助 于 其 他 手段 来 进行 ， 如 FTP 或 SSH 协 议 等 ， 另 外 ， 如 需 自 建 
Charts 仓 库 ， 则 各 流行 的 Web 服务 器 程序 基本 上 都 能 满足 要 求 ， 如 
Apache 或 Nginx 等 。 安 全 起 见 ， 通 过 互联 网 提供 服务 时 ， 建 议 使 用 
HTTPS 的 服务 器 提供 仓库 服务 。 


而 在 Helm 客 户 端 ， 仓 库 的 管理 需要 使 用 “helm repo” 命 令 进行 ， 它 可 
以 添加 、 删 除 、 列 出 、 及 索引 仓库 。 例 如 ， 使 用 如 下 命令 添加 incubator 
仓库 以 便 使 用 更 多 的 Charts: 





~]$ helm repo add incubator http://storage.googleapis.com/kubernetes-charts-incubatc 
"incubator" has been added to your repositories 





列 出 所 有 可 用 的 仓库 列表 ， 可 以 使 用 “helm repo list”* 命 令 进 行 : 





~]$ helm repo list 


NAME URL 
stable https://kubernetes-charts.storage.googleapis.com 
local http://127.0.0.1:8879/charts 


incubator http://storage.googleapis.com/kubernetes-charts-incubator 





仓库 服务 器 上 的 可 用 Charts 及 其 版 本 等 经 常会 发 生 更 新 ， 必 要 时 ， 
可 使 用 “helm repo update” 命 令 获 取 最 新 的 仓库 元 数据 信息 : 





~]$ helm repo update 

Hang tight while we grab the Jatest from your chart repositories... 
,.,Sklip local chart repository 

...Successfully got an update from the "stable" chart repository 
...Successfully got an update from the "incubator" chart repository 
Update Complete. *Happy Helming! * 





而 要 删除 指定 的 仓库 配置 ，“helm repo remove<REPO_NAME>” 即 
可 轻松 完成 。 
4. 配 置 依赖 关系 

构建 存在 依赖 关系 的 Charts 时 ， 还 需要 为 其 定义 依赖 项 ， 例 如 ， 前 
面 创建 的 myapp 依 赖 于 数据 库 管 理 系统 MySQL 时 ， 在 mychart 的 目录 中 


创建 requirements.yaml 文 件 给 出 依赖 的 Charts 列 表 定 义 其 依赖 关系 即 可 ， 
文件 内 容 类 似 如 下 所 示 : 





dependencies: 
- name: mysql 
version: 0.6.0 
repository: https://kubernetes-charts.storage.googleapis.com 





而 后 ， 需 要 运行 “helm dependency update” 命 令 为 Charts 更 新 依赖 关 
系 。 更 新 过 程 中 ，Helm 会 自动 生成 一 个 锁定 文件 requirements.lock， 以 
便 后 续 再 次 获取 依赖 关系 时 使 用 已 知 的 工作 版 本 。 运 行 下 面 的 命令 来 引 
入 定义 的 MySQL 依 赖 项 时 ， 会 自动 下 载 MySQL 相 关 的 Charts 程 序 包 至 
mychart/charts 子 目录 中 ， 如 下 面 的 命令 输出 结果 所 示 : 





~]$ helm dependency update ./mychart 

Hang tight while we grab the latest from your chart repositories... 

Saving 1 charts 

Downloading mysql1 from repo https://kubernetes-charts.storage.googleapis.com 
Deleting outdated charts 





此 时 ， 再 次 部 署 myapp Charts， 就 会 同时 部 署 依赖 到 的 mysql 
Charts。 另 外 ， 用 户 也 可 以 手动 将 所 依赖 到 的 程序 包 直 接 放置 于 
mychart/charts 目 录 中 来 定义 依赖 关系 ， 此 时 不 必要 再 使 用 


requirements.yaml 文 件 。 


15.3 Helm 实 践 : 部 闭 EFK 日 志 管 理 系 统 


应 用 程序 的 日 志 收 集 和 监控 通常 是 其 必要 的 外 围 功 能 ， 它 们 有 助 于 
记录 、 分 析 性 能 表现 及 排查 故障 等 ， 例 如 此 前 在 查看 Pod 对 象 的 日 志 时 
使 用 的 kubectl log 命 令 便 是 获取 容 右 化 应 用 日 志 的 一 种 方式 。 然 而 ， 对 
于 分 布 式 部 署 的 应 用 来 说 ， 类 似 这 种 逐一 查看 各 实例 相关 日 志 的 方式 存 
在 着 操作 烦琐 且 效 率 低下 等 诸多 问题 ， 再 加 上 需要 额外 获取 操作 系统 级 
别 的 多 个 日 志 源 中 的 日 志 信息 ， 其 管理 成 本 势必 会 进一步 上 上升。 解雇 此 
类 需求 的 常见 方案 是 使 用 集中 式 日 志 存 信和 管理 系统 ， 它 们 于 各 节点 部 
署 日 志 采 集 代 理 程序 从 日 志 源 采集 日 志 并 发 往 中 心 存储 管理 系统 ， 并 经 
由 单个 面板 进行 数据 可 视 化 。 事 实 上 ， 对 于 任何 基础 设施 或 分 布 式 系 
统 ， 统 一 日 志 管 理 都 是 必 不 可 少 的 基础 组 件 。 同 样 地 ，Kubernetes 也 要 
实现 在 整个 集群 级 别 收 集 和 聚合 日 志 ， 以 便 用 户 可 以 从 单个 仪表 板 监控 
整个 集群 ， 其 常用 的 架构 形式 之 一 ， 如 图 15-3 所 示 。 一 种 流行 的 开源 解 
决 方案 是 将 fluentd 作 为 节点 级 代理 程序 进行 日 志 有 采集， 并 将 之 聚合 存储 
于 Elasticsearch 进 行 日 志 分 析 ， 以 及 通过 Kibana 进 行 数据 可 视 化 。 这 种 组 
合 通常 简称 为 EFK。 
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图 15-3 ”基于 市 反日 志 采 集 代 理 完成 日 志 收 集 


在 Kubernetes 上 部 署 fuentd 和 Kibana 的 方式 易于 实现 ，fluentd 由 
DaemonSset 控 制 器 部 普 于 集群 中 的 各 节点 ， 而 Kibana 则 由 Deployment 控 
制 妖 部 署 并 确保 其 持续 运行 即 可 。 但 Elastic-Search 是 一 个 有 状态 的 应 
用 ， 需 要 使 用 StatefulSet 控制 器 创建 并 管理 相关 的 Pod 对 象 ， 而 且 它 们 还 
分 别 需要 专用 的 持久 存储 系统 存储 日 志 数 据 ， 因 此 ， 其 部 署 过 程 较 之 前 
两 者 要 略为 烦琐 ， 其 部 署 架 构 如 图 15-4 所 示 。 





Kubernetes cluster 


Elasticsearch cluster 





图 15-4 “Kubernetes 集 群 上 的 fluentd、Elastic- search 和 Kibana 


可 用 的 部 普 方 式 除了 Kubernetes 项 目 在 其 Addons 目 录 中 提供 了 资源 
配置 清单 用 于 部 署 EFK 之 外 ，Kubeapps (https://hub.kubeapps.com ) 也 
I 以 帮助 用 户 通过 Helm 轻 松 完成 其 
部 署 。 


15.3.1 ”ElasticSearch 和 集群 


ElasticSearch 相 关 Charts 位 于 Kubeapps 的 incubator 仓 库 中 ， 它 使 用 
StatefulSet 和 Deployment 控 制 器 实现 了 一 个 可 动态 伸缩 的 ElasticSearch 集 
群 ， 并 将 集群 的 角色 分 离 为 三 类 节点 : 客户 端 节点 (上载 节 点 )、 
master 节 点 和 data 节 点 ， 各 上 自 负载 实现 集群 的 一 部 分 功能 ， 如 图 15-5 所 
示 。 每 个 master 节 点 和 data 节 点 分 别 需 要 用 到 各 上 自 的 存储 卷 以 持久 存储 
数据 ，incubator/elasticsearch 上 默认 定义 它 们 通过 PVC 依 赖 于 default 或 指定 
的 存储 类 动态 创建 PV 存储 卷 。 
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图 15-5 ”多 角色 ElasticSearch 集 群 


客户 正 贡 氮 : 也 称 上 载 节 点 或 摄取 节点 ， 负 责 执行 由 一 个 或 多 个 
摄取 处 理 器 组 成 的 预 处 理 流 水 线 。 需 要 两 个 以 上 客户 端 实例 的 场景 并 不 
多 见 ， 因 此 其 副本 数 通 种 为 2。 





-master 记 太 : 负责 轻 量 级 群集 范围 的 相关 操作 ， 如 创建 或 删除 家 
引 、 跟 踪 并 判定 集群 的 成 员 节 点 ， 以 及 决定 将 哪些 分 片 分 配 到 哪些 布点 
等 ， 因 此 ， 一 个 健康 的 集群 必须 要 有 一 个 稳定 的 主 节 点 。masterT 点 的 
数量 取决 于 公式 “(客户 端 副 本 数 /2) +1” 的 计算 结果 ， 但 至 少 应 该 为 





数据 节点 : 负责 保存 包含 编 入 索引 的 文档 的 分 片 ， 并 处 理 与 数据 
相关 的 操作 ， 例 如 数据 的 增删 改 查 〈CRUD ) 、 搜 索 和 聚合 等 ， 这 些 操 
作 通 第 是 VO、 内 存 和 CPU 密 集 型 的 任务 ， 其 所 需 的 广 皮 数量 取决 于 存 
储 及 计算 的 实际 需求 ， 因 此 ， 监 视 这 些 资源 并 在 过 载 时 添加 更 多 的 数据 
节点 非常 重要 。 


incubatorelasticsearch 的 部 署 模板 中 定义 了 众多 配置 参数 ， 随 着 
Charts 版 本 的 迭代 ， 各 参数 的 默认 值 也 可 能 会 有 变动 ， 当 前 的 0.4.9 版 本 
中 ， 使 用 的 镜像 来 自 仓 库 “centerforopenscience/elasticsearch”， 镜 像 文 件 
的 标签 为 “5.42， 各 master 节 点 的 PVC 存 储 卷 大 小 都 是 4Gi， 各 data 节 点 的 
PVC 存 储 卷 大 小 均 为 30Gi，rbac 相 关 的 各 资源 创建 为 禁用 状态 。 部 署 于 
生产 环境 时 ， 默 认 设 置 中 的 资源 请 求 和 资源 限制 ， 以 及 data 市 点 的 PVC 
存储 卷 空间 等 较 小 ， 而 且 在 启用 了 rbac 授 权 插 件 的 集群 中 还 需要 创建 
elasticsearch 所 需要 的 各 ClusterRole 及 ClusterRoleBinding 资 源 。 这 些 需 要 
自 定义 的 配置 参数 可 以 通过 values 文 件 进 行 设置 ， 或 者 直接 由 “helm 
instal]* 命 令 的 “--set* 选 项 提供 。 一 个 示例 性 的 values 文 件 (els- 
values.yaml) 如 下 所 示 : 











# This is a YAML-formatted file. 
# Declare variables to be passed into your templates. 
appVersion: "5.5" 


image: 
repository: "centerforopenscience/elasticsearch" 
tag: "5.5" 
pullPolicy: "IfNotPresent" 
cluster: 
name: "elasticsearch" 
config: 


enyv ， 
MINIMUM_MASTER_NODES: "2" 


client: 
name: client 
replicas: 2 
serviceType: ClusterIP 
heapSize: "2048m" 
antiAffinity: "soft" 
resources: 
limits: 
cpu: Cs 
# memory: "8192Mi" 
requests: 
cpu: "25m" 
memory: "2048Mi" 


master : 
name: master 
exposeHttp: false 
replicas: 3 
heapSize: "2048m" 
persistence: 
enabled: true 
accessMode: Readwriteonce 
name: data 
size: "46Gi" 
#storageClass: "glusterfs" 
antiAffinity: "soft" 
resources: 
limits: 
cpu: Ws 
# memory: "8192Mi" 
requests: 
cpu: "25m" 
memory: "2048Mi" 


data: 
name: data 
exposeHttp: false 
replicas: 2 
heapSize: "4096m" 
persistence: 
enabled: true 
accessMode: Readwriteonce 
name: data 
size: "120Gi" 
#storageClass: "glusterfs" 
terminationGracePeriodSeconds: 3600 
antiAffinity: "soft" 
resources: 
limits: 
cpu: i 
# memory: "16384Mi" 
requests: 
cpu: "25m" 
memory: "4096Mi" 


## Install Default RBAC roles and bindings 
rbac: 
create: true 





需要 特别 说 明 的 是 ， 未 明确 定义 持久 存储 使 用 的 存储 类 时 ， 无 须 持 
久保 存 数 据 ， 或 者 无 可 用 的 实现 动态 供给 PV 的 存储 时 ， 也 可 以 使 用 
emptyDir 存 储 卷 ， 实 现 方法 是 将 上 面 示例 中 master.persistence.enabled 和 
data.persistence.enabled 配 置 参 数 的 值 分 别 设置 为 “false”。 





名 提示 incubatorelasticsearch 相 关 的 配置 参数 列表 获取 地 址 


为 https://github.com/kubernetes/charts/tree/master/incubator/elasticsearch 。 








下 称 空间 中 部 署 ElasticSearch 集 群 的 各 角色 及 其 
相关 的 其 他 资源 ， 其 通过 前 面 示例 中 的 Wihes 文 件 elsnwalueswamil 关 到 各 
自 定 义 的 配置 参数 : 





~]$ kubectl create namespace logs 
~]$ helm install incubator/elasticsearch -n efk-els --namespace=logs -f els- 
values.yaml 





@ 提示 仅 用 于 测试 ， 且 无 可 用 的 实现 动态 供给 PV 的 存储 类 
时 ， 则 无 须 定 义 Values 文 件 ， 并 将 上 面 的 命令 蔡 换 为 "helm install 
incubatorelasticsearch-n efk-els--namespace=logs--set 
master.persistence.enabled="false", data.persistence.enabled="false", 
rbac.create= "true"”B| 9] 。 


从 命令 最 后 提供 的 类 似 如 下 的 提示 信息 中 可 以 看 出 ， 部 署 完 成 后 在 
Kubernetes 集 群 内 部 访问 ElasticSearch 服 务 的 接 入 端点 为 “efk- 
elasticsearch-client.logs.svc.cluster.local: 9200”。 随 后 部 署 fluentd 时 将 基 
于 此 访问 端点 将 采集 到 的 日 志 导 入 到 ElasticSearch 集 群 中 ， 而 Kibana 也 
将 通过 此 端点 为 ElasticSearch 中 的 数据 提供 可 视 化 的 搜索 及 展示 接口 : 








NOTES : 
The elasticsearch cluster has been installed. 


Elasticsearch can be accessed: 
* Within your cluster, at the following DNS name at port 9200 : 


efk-els-elasticsearch-client,1ogs.Svc,Ccluster ,1ocal 





使 用 cirros 镜 像 创 建 一 个 测试 客户 端 ， 通 过 此 端点 对 ElasticSearch 的 
服务 发 起 测试 访问 请 求 。 例 如 ， 下 面 的 命令 可 用 于 请 求 显 示 
ElasticSearch 集 群 的 欢迎 信息 : 





~]$ kubectl1 run cirros-$RANDOM --rm -it --image=cirros -- sh 
/ # curl http://efk-els-elasticsearch-client.1ogs.svc.cluster.1local:9200 


"name" :; "efk-els-elasticsearch-client-55dccf5f75-7hhc9", 
"cluster_name" : "elasticsearch", 
"cluster_uuid" : " uGffeDS5bSo08q29v4uLaBw", 


"version™" : { 
"number™ :; "5.5.2", 
"build_ hash" :; "b2f0Oc09", 
"build _ date" : "2017-08-14T12:33:14.1542Z", 
"build_ snapshot" : false, 
"Jucene_version" : "6.6.0" 


也 
"tagline" :; "You Know, for Search" 


} 
/ # 





还 可 以 通过 类 似 如 下 的 命令 了 解 ElasticSearch 集 群 当前 的 工作 状 
态 ， 它 显示 出 当前 集群 处 于 正常 工作 状态 “green”"， 共 有 7 个 节点 ， 其 中 
a 由 于 是 新 创建 的 集群 ， 因 此 目前 尚 不 存在 任何 
数据 分 斤 : 








/# curl http://efk-els-elasticsearch-client.1ogs.Ssvc,.Ccluster.1ocal:9200/_clustery/ 
healthpretty 
{ 


"cluster_name" : "elasticsearch", 
"status" : "green", 

"timed out" : false, 
"number_of_nodes" :; 7, 
"number_of_data nodes" : 2, 
"active_primary_shards" : 0, 
"active_shards" : 0, 


15.3.2 ”日 志和 采集 代理 fluentd 


fluentd 是 一 个 开源 的 数据 收集 器 ， 基 于 C 和 Ruby 语 言 开发 ， 它 目前 
有 数 百 种 以 Ruby Gem 形 式 独 立 存 在 的 可 选 插 件 ， 用 于 连接 多 种 数据 源 
和 数据 输出 组 件 等 ， 如 fluent-plugin-elasticsearch 插 件 用 于 实现 将 采集 到 
的 数据 发 送 给 ElasticSearch。 


@ fluentd 的 可 用 插件 列表 获取 地 址 
为 https://www .fluentd.org/plugins 。 


运行 时 ，fluentd 从 配置 文件 获取 数据 源 、 数 据 和 输出 目标 、 过 滤器 等 
相关 的 配置 信息 ， 这 些 配置 信息 以 source、match、filter、system、1label 
和 @include 配 置 参数 给 出 。 
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图 15-6 fluentd 架 构图 
Source: 定义 数据 源 ， 每 个 数据 源 都 需要 有 其 专 有 类 型 的 定义 。 
match: 数据 输出 的 目标 位 置 ， 如 文件 或 各 种 存储 系统 。 
-filter: 过 滤器 ， 即 事件 处 理 流水 线 ， 通 常 运行 于 输入 和 输出 之 








system: 系统 级 设置 ， 如 处 理 嚣 名称 等 。 
-label: 用 于 分 组 过 滤器 及 输出 目标 。 
`@include: 引用 配置 信息 中 某 些 已 有 的 定义 ， 以 达到 配置 复 用 之 目 





的 。 





下 面 的 配置 示例 中 给 出 了 fluentd 收 集 Kubernetes 平 台 上 容器 日 志 的 
输入 及 输出 相关 的 定义 : 





<source> 
@id fluentd-containers,1og 
@type tail 
path /var/log/containers/*.1og 
pos_file /var/log/fluentd-containers.1o0g.pos 
time_format %Y-%m-%dT%H:%M:%S,.%NZ 
tag raw.kubernetes.* 
format json 
read_ from head true 

</source> 

<match raw.kubernetes.**> 
Q@id raw.kubernetes 
@type detect_ exceptions 
remove_tag_prefix raw 
message log 
stream stream 
multiline_flush_interval 5 
max_bytes 500000 
max_lines 1000 

</match> 





incubatorfluentd-elasticsearch 是 Kubeapps 上 和 定义 的 基于 fluentd 收 集 容 
器 及 系统 日 志 并 将 其 输出 至 ElasticSearch 中 的 Charts 之 一 ， 它 内 置 了 基于 
ConfigMap 资 源 定义 的 fluentd 配 置 文件 ， 基 本 无 须 修 改 即 能 入 使 用 。 
男 外 ，fluentd 是 运行 于 各 节点 上 的 日 志 末 集 代 理 ， 因 此 ， 它 受 控 于 
DaemonSet 控 制 器 。 





基于 此 Charts 部 署 fluentd 时 通常 仅 需 为 其 指定 ElasticSearch 服 务 的 访 
问 端点 即 可 ， 因 此 可 直接 基于 命令 局 动 部 署 操 作 : 











~]$ helm install local/fluentd-elasticsearch -n efk-flu --namespace=]1ogs \ 
--Set elasticsearch.host="efk-els-elasticsearch-client.1logs.svc.cluster.local" 








不 过 ， 知 需要 收集 master 节 点 上 的 日 志 ， 就 需要 为 部 署 的 Pod 对 象 
添加 tolerations 以 容忍 master 上 的 taints。 修 改 Charts 中 默认 的 values.yaml 
文件 中 的 配置 ， 并 以 之 完成 部 署 即 能 实现 。 


确认 fluentd 相 关 的 各 Pod 对 象 正常 运行 之 后 ， 即 可 到 ElasticSearch 集 
群 中 查看 其 收集 并 存储 的 日 志 的 索引 及 数据 信息 ， 例 如 ， 仍 于 此 前 启动 
的 测试 Pod 中 辐 ElasticSearch 发 起 访问 请 求 ， 查 看 已 生成 的 索引 ， 命 令 如 
下 : 





/ # curl http://efk-els-elasticsearch-client.1logs,.svc.cluster.local:9200/_cat/indice 
green open logstash-2018.06.10 UJtHdGeHTISVFkW8s0_PjQ 51 6 © 337.3kb 168.6kb 


green open logstash-2018.06.09 eotV9S2QQuCK1JUPEnmieQ 5 1 47470 © 97.6mb 48.9mb 
/ # 





命令 结果 中 显示 出 以 “logstash-YYYY.MM.DD” 格 式 命名 的 索引 列 
表 ， 即 表示 fluentd 已 经 能 够 正常 采集 到 日 志 数据 并 输出 到 指定 的 
ElasticSearch 和 集群 中 。 


15.3.3 “可视化 组 件 Kibana 


Kibana 是 ElasticSearch 的 数据 分 析 及 可 视 化 平台 ， 能 够 用 来 搜索 、 
查看 存储 在 Elastic-Search 索 引 中 的 数据 。 它 可 以 通过 各 种 图 表 进 行 高 级 
数据 分 析 及 展示 ， 用 户 基于 Web GUI 可 以 快速 创建 仪表 板 (dashboard) 
实时 显示 ElasticSearch 的 查询 结果 。Kibana 配 置 过 程 简单 便捷 ， 图 形 样 
式 丰 富 ， 可 借助 于 ElasticSearch 创 建 柱 形 图 、 折 线 图 、 散 点 图 、 直 方 
图 、 饼 图 和 地 图 等 数据 展示 接口 。Kibana 增 强 了 ElasticSearch 的 数据 分 
析 能 力 ， 让 用 户 能 够 更 加 智能 地 分 析 数 据 和 展示 数据 。 


类 似 于 fluentd，Kibana 也 通过 URL 访 问 ElasticSearch， 但 它 要 通过 环 
境 变量 ELASTIC-SEARCH_URL 来 指定 。 部 署 于 Kubernetes 上 的 Kibana 
一 般 会 由 集群 外 的 客户 端 访 问 ， 因 此 需要 为 其 配置 mgress 资 源 ， 也 可 以 
使 用 NodePort 或 LoadBalancer 类 型 的 Service 资 源 进 行 服务 暴露 。 它 默认 
通过 HTTP 提 供 服 务 ， 在 使 用 mngress 暴 露 到 互联 网 时 ， 建 议 将 其 配置 为 
HTTPS 类 型 的 服务 。 


stable/kibana 是 Kubeapps 上 提供 的 Charts， 下 和 面 是 适用 于 当前 配置 环 
境 设 定 的 Values 文 件 〈kibana-values.yaml) ， 它 使 用 镜像 文件 kibana: 
5.5 运 行 容器 ， 环 境 变量 ELASTICSEARCH _UREL 的 值 为 前 面部 署 的 
ElasticSearch 集 群 的 访问 接口 ， 并 通过 NodePort 类 型 的 Service 资 源 进行 
服务 骑 露 : 




















Image : 
repository: "kibana" 
tag: "5.5" 
pullPolicy: "IfNotPresent" 


env: 
ELASTICSEARCH_URL: http://efk-els-elasticsearch-client.1ogs.svc:9200 
SERVER_PORT: 5601 


service: 
type: NodePort 
externalPort: 443 
internalPort: 5601 


ingress: 
enabled: false 





而 后 ， 使 用 下 面 的 命令 即 可 完成 Kibana 部 署 : 


一 一 


~]$ helm install stable/kibana -n efk-kib --namespace=]logs -f kibana-values.yaml 
NAME : efk-kib 
LAST DEPLOYED: Sun Jun 10 09:19:49 2018 


RESOURCES : 

==> V1/Service 

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
efk-kib-kibana NodePort 10.110.201.6 <none> 443:30978/TCP 0s 





确认 相关 的 Pod 资 源 能 够 正常 运行 之 后 ， 即 可 通过 如 上 面 命 令 显 示 
的 Service 资 源 中 30978 端 口 于 集群 外 访问 Kibana， 其 初始 界面 如 图 15-7 
所 示 。 在 “Management” 中 添加 相应 的 索引 模式 加 载 相 关 的 索引 数据 即 可 
完成 数据 搜索 及 可 视 化 配置 ， 由 fluentd 收 集 的 日 志 以 "logstash- 
YYYY.MM.DD” 为 索引 名 根据 索引 产生 的 日 志 按 天 保存 于 单独 的 索引 
中 ， 因 此 Kibana 默 认 的 模式 "logstash-*>” 便 能 够 加 载 这 些 索引 中 的 数据 。 














”CO 172.16.0.67:30978/app/Kibana#/management/kibana/index?_g=0 
Management / Kibana 
Index Patterns Saved Objects Advanced Settings 





© 


4 
No 7 Index pattern, You must select or create one to continue. 


医 


Configure an index pattern 


In orderto use Kibana you must configure at least one index pattern, Index patterns are used to identify the 
Elasticsearch index to run search and analytics against. They are also used to configure fields. 


Index name or pattern 


© 
可 
£ 
册 M 


logstash-* 
Patterns allow you to define dynamic index names using * as a wildcard. Example; logstash"* 
Time Filter field name ©@ refresh flelds 
@timestamp 
Expand index pattern when searching [DEPRECATED]) 


With this option selected, searches against any time-based index pattern that contains a wildcard will automatically be 
expanded to query only the indices that contain data within the currenthy selected time range 


Searching against the index pattern /ogstash-*will actually query Elasticsearch for the specific matching indices (e.g, /ogstash- 
2015.12.21 ) that fall within the current time range, 


With recent changes to Elasticsearch, thls option should no longer be necessary and will likely be removed In future versions of 
Kibana. 


Use event times to create index names [DEPRECATED]) 





图 15-7 ”Kibana 的 初始 界面 


创建 好 索引 模式 之 后 ， 即 可 通过 “Discover 搜 索 数据 ， 或 者 
在 “Visualize” 界 面 中 定义 可 视 化 图 形 ， 并 将 它们 集成 于 可 
在 “Dashboard” 中 创建 的 仪表 板 里 。 


© 注意 “Kibana 程 序 〈 非 Charts) 的 版 本 号 不 能 高 
ElasticSearch， 人 个 则 会 导致 不 兼容 。 





15.4 本 章 小 结 


目前 来 说 ，Kubernetes 部 署 及 管理 应 用 程序 的 接口 仍然 相当 复杂 ， 
在 维护 较 多 的 资源 时 ， 用 户 必 然 会 受 困 于 其 复杂 多 变 的 资源 配置 清单 ， 
Helm 通 过 Charts 实 现 了 类 似 于 yum、dnf 或 apt-get 等 程序 包 管 理 妖 的 功 
能 ， 大 大 降低 了 用 户 的 使 用 成 本 。 本 章 详 细 讲 解 了 Helm 的 使 用 方式 ， 
并 通过 示例 演示 了 其 使 用 方法 。 











附录 A ” 部署 Kubernetes 集 群 


A.1 准备 部 普 Kubernetes 集 群 


Kubernetes 项 目 目 前 仍然 处 于 快速 迭代 阶段 ， 演 示 过 程 中 使 用 的 配 
置 对 于 其 后 续 版 本 可 能 存在 某 些 变动 ， 因 此 ， 版 本 不 同时 ， 对 具体 特性 
支持 的 变动 请 读者 参考 Kubernetes 的 ChangeLog 或 其 他 相关 文档 中 的 说 


明 。 











A.1.1 部 署 目标 


图 A-1 给 出 了 本 市 要 部 署 的 目标 集群 的 基本 环境 ， 它 拥有 一 个 
Master 主 机 和 三 个 Node 主 机 。 各 Node 主 机 的 配置 方式 基本 相同 。 





Service 网 络 : 10.96.0.0/12 
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kube-proxy Pod 
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Pod 网 络 : 10.244.0.0/16 


图 A-1 Kubernetes 集 群 部 署 目 标示 意图 


各 主机 上 采用 的 容器 运行 时 环境 为 Docker， 为 Pod 提 供 网 络 功能 的 
CNI 是 fannel， 它 运行 为 托管 于 Kubernetes 之 上 的 Pod 对 象 ， 另 外 ， 基 础 
附件 还 包括 KubeDNS (或 CoreDNS) 用 于 名 称 解 析 和 服务 发 现 。 


A.1.2 系统 环境 及 部 辕 准备 


如 前 所 述 ，Kubernetes 当 前 仍 处 于 快速 迭代 的 周期 中 ， 其 版 本 变化 
频繁 、 跨 版 本 的 特性 变化 较 大 ， 为 了 帮助 读者 确认 各 配置 和 功能 的 可 用 
性 ， 本 书 使 用 如 下 基础 环境 。 

1. 各 相关 组 件 及 主机 环境 

操作 系统 、 容 器 引擎 、etcd 及 Kubernetes 的 相关 版 本 分 别 如 下 。 

‘OS: Cent OS 7.5x86_64 

-Container runtime: Docker 18.06.ce 

-Kubermnetes: 1.12 

各 主机 角色 分 配 及 IP 地 址 如 表 A-1 所 示 。 


表 A-1 Kubernetes 集 群 的 主机 环境 





FM 和 
172.16.0.70 master. InasterI.1linUX.1o master 
172.16.0.66 node 
172.16.0.67 node 
172.16.0.68 node 

2. 基 础 环境 设置 


Kubernetes 的 正确 运行 依赖 于 一 些 基 础 环境 的 设 定 ， 如 各 节点 时 间 
通过 网 络 时 间 服 务 保持 同步 和 主机 名 称 解析 等 ， 集 群 规模 较 大 的 实践 场 
景 中 ， 主 机 名 称 解 析 通 常 由 DNS 服 务 器 完成 。 本 测试 示例 中 ， 时 间 同 步 
服务 直接 基于 系统 的 默认 配置 从 互联 网 的 时 间 服 务 中 获取 ， 主 机 名 称 解 
析 则 由 hosts 文 件 进行 。 


(1) 主机 名 称 解析 


分 布 式 系 统 环境 中 的 多 主机 通信 通常 基于 主机 名 称 进 行 ， 这 在 IP 地 
址 存在 变化 的 可 能 性 时 为 主机 提供 了 固定 的 访问 入 口 ， 因 此 一 般 需要 有 
专用 的 DNS 服 务 负 责 解 决 各 市 点 主机 名 。 不 过 ， 考 虑 到 此 处 部 署 的 是 测 
试 集群 ， 因 此 为 了 降低 系统 的 复杂 上 度 ， 这 里 将 采用 基于 hosts 的 文件 进行 
主机 名 称 解 析 。 编 辑 Master 和 各 Node 上 的 /etc/hosts 文 件 ， 确 保 其 内 容 如 











下 : 





172.16.0.66 node01.ilinux.io node01 
172.16.0.67 node02.ilinux.io node02 
172.16.0.68 node03.ilinux.io node03 
172.16.0.70 master. ilinux.io master 





(2) 主机 时 间 同 步 


如 有 果 各 主机 可 直接 访问 互联 网 ， 则 直接 启动 各 主机 上 的 chronyd 服 
务 即 可 。 人 否则 需要 使 用 本 地 网 络 中 的 时 间 服 务 器 ， 例 如 ， 可 以 将 Master 
配置 为 chrony server， 而 后 其 他 节点 均 从 Master 同 步 时 间 : 

















~]# SystemctJl start chronyd.service 
~]# SystemctJ enable chronyd.service 





(3) 关闭 防火 墙 服务 


各 Node 运 行 的 kube-proxy 组 件 均 要 借助 iptables 或 ipvs 构 建 Service 资 
源 对 象 ， 该 资源 对 象 是 Kubernetes 的 核心 资源 之 一 。 出 于 简化 问题 复杂 
上 度 之 需 ， 这 里 需要 事先 关闭 所 有 主机 之 上 的 iptables 或 firewalld 服 务 : 





~]# SystemctJ stop firewalld. service iptables.service 
~]# Systemctl1 disable firewalld.service 
~]# Systemctl1 disable iptables.service 





(4) 关闭 并 禁用 SELinux 


若 当前 启用 了 SELinux， 则 需要 临时 设置 其 当前 状态 为 permissive: 





~]# setenforce 0 





另外 ， 编 辑 /etc/sysconfig/selinux 文 件 ， 以 彻底 禁用 SELinux: 





~]# sed -i 's@^\(SELINUX=\).*@\1disabled@' /etc/sysconfig/selinux 





(5) 禁用 Swap 设 备 《〈 可 选 步骤 ) 


kubeadm 默 认 会 预先 检查 当前 主机 是 人 否 茶 用 了 Swap 设 备 ， 并 在 未 茶 
用 时 强制 终止 部 署 过程 。 因 此 ， 在 主机 内 存 资源 充 座 的 条 件 下 ， 雷 要 禁 
用 所 有 的 Swap 设 备 。 


关闭 Swap 设 备 ， 需 要 分 两 步 完成 。 首 先是 关闭 当前 已 局 用 的 所 有 


Swap 设 备 : 











~]#swapoff-a 





而 后 编辑 /etc/fstab 配 置 文 件 ， 注 释 用 于 挂 载 Swap 设 备 的 所 有 行 。 不 
同系 统 环 境 默 认 启 用 的 Swap 设 备 不 尽 相 同 ， 请 读者 根据 实际 情况 完成 
相应 操作 。 男 外 ， 部 署 时 也 可 以 选 不 禁用 Swap， 而 是 通过 后 文 的 
kubeadm init 及 kubeadm join 命 令 执 行 时 额外 使 用 相关 的 选项 忽略 检查 错 
误 。 





(6) 启用 ipvs 内 核 模 块 (可 选 步 又 》 


Kubernetes 1.11 之 后 的 版 本 默认 支持 使 用 ipvs 代 理 模 式 的 Service 资 
源 ， 但 它 依 赖 于 ipvs 相 关 的 内 核 模块 ， 而 这 些 模 块 默认 不 会 自动 载 入 。 
因此 ， 这 里 选择 创建 载 入 内 核 模 块 相关 的 脚本 文 
件 /etc/sysconfig/modules/ipvs.modules， 设 定 于 系统 引导 时 自动 载 入 的 
了 的 内 核 模 块 ， 以 文 持 使 用 ipvs 代 理 模 式 的 Service 资 源 。 文 件 内 
容 如 下 : 





#!/bin/bash 
ipvs_mods_dir="/usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs" 
for i In $(ls $ipvs_mods_ dir | grep -o "^[^.]*"); do 

/sbin/modinfo -F filename $i &> /dev/null 

if [$ -eq 0 ]; then 

/sbin/modprobe $i 

fi 

done 





而 后 ， 修 改 文件 权限 ， 并 手动 为 当前 系统 环境 加 载 内 核 模 志 : 





~]# chmod +x /etc/sysconfig/modules/ipvs.modules 
~]# /etc/sysconfig/modules/ipvs.modules 


不 过 ，ipvs 仅 负责 实现 负载 均衡 相关 的 任务 ， 它 无 法 完成 kube- 
proxy 中 的 包 过 滤 及 SNAT 等 功能 ， 这 些 仍 需要 由 iptables 实 现 。 另 外 ， 对 
前 期 的 测试 并 非 必 然 要 用 到 ipvs 代 理 模式 ， 部 蜀 时 可 省 

此 步 又 


A.2 ”部署 Kubernetes 集 群 


kubeadm 是 用 于 快速 构建 Kubernetes 集 群 的 工具 ， 随 着 Kubernetes 的 
发 行 版 本 而 提供 ， 使 用 它 构建 集群 时 ， 大 致 可 分 为 如 下 几 步 。 


1) 在 Master 及 各 Node 安 装 Docker、kubelet 及 kubeadm， 并 以 系统 守 
护 进 程 的 方式 启动 Docker 和 kubelet 服 务 。 


2) 在 Master 节 点 上 通过 kubeadm init 命 令 进 行 集群 初始 化 。 
3) 各 Node 通 过 kubeadm join 命令 加 入 初始 化 完成 的 集群 中 。 


4) 在 集群 上 部 署 网 络 附件 ， 如 flannel 或 Calico 等 以 提供 Service 网 络 
及 Pod 网 络 。 


为 了 简化 部 普 过 程 ，kubeadm 使 用 一 组 固定 的 目录 及 文件 路 径 存储 
相关 的 配置 及 数据 文件 ， 其 中 /etckubernetes 目 录 是 所 有 文件 或 目录 的 统 
一 存储 目录 。 它 使 用 /etc/kubernetes/manifests 目 录 存 储 各 静态 Pod 资 源 的 
配置 清单 ， 用 到 的 文件 有 etcd.yaml、kube-apiserver.yaml、kube- 
controller-manager.yaml 和 kube-scheduler.yaml 四 个 ， 它 们 的 作用 基本 能 
够 见 名 知 义 。 男 外 ，/etc/kubernetes/ 目 录 中 还 会 为 Kubernetes 的 多 个 组 件 
存储 专用 的 kubeconfig 文 件 ， 如 kubelet.conf、controller-manager.conf、 

scheduler.conf 和 conf 等 ， 它 们 分 别 为 相关 的 组 件 提供 接 入 API 
Server 的 认证 信息 等 。 此 外 ， 它 还 会 在 /etc/kubernetes/pki 目 录 中 存储 若 
干 私 钥 和 证 书 文 件 。 








A.2.1 设 定 容 器 运行 环境 





Kubernetes 支 持 委 0 运行 时 环境 ， 例 如 Docker、RKT 和 Frakti 
等 ， 本 书 将 采用 其 中 目 ， 接受 程度 最 为 广泛 的 Docker， 它 








的 种 用 部 车 方式 有 两 种 ， 有 具体 如 下 。 


:由 系统 发 行 版 的 程序 包 仓 库 提 供 ， 如 Cent OS 7Extras 仓 库 中 的 
Docker。 


.Docker 官 方 仓 库 中 的 程序 包 ， 以 Cent OS 7 为 例 ， 它 通常 能 够 提供 
较 Extras 仔 库 中 更 新 版 本 的 程序 包 ， 获 取 地 址 
为 https://download.docker.com/ 。 


本 文采 用 的 是 第 二 种 方式 ， 不 过 ，Kubernetes 认 证 的 Docker 版 本 通 
第 上 略 低 于 其 最 新 版 本 ， 因 此 生产 环境 部 署 时 应 该 尽 可 能 部 署 经 过 认证 的 
版 本 。 考 虑 到 Kubermnetes 版 本 迭代 周期 较 短 ， 它 对 Docker 版 本 的 支持 也 
会 快速 变化 ， 因 此 本 示例 将 直接 使 用 Docker 仓 库 中 的 最 新 版 本 。 部 署 
时 ，Docker 需 要 安装 于 Master 及 各 Node 主 机 之 上 ， 安 装 方式 相同 ， 其 步 
骤 如 下 : 











~]# wget https://download,.docker.com/linux/centos/docker-ce.repo \ 
-0 /etc/yum,.repos.d/docker-ce.repo 
~]# yum install docker-ce 





© 注意 ”kubeadm 构 建 集群 的 过 程 需 要 a 到 gcr.io 中 获取 Docker 镜 
像 ， 因 此 必须 确保 Docker 主 机 能 够 正常 访问 到 此 站 点 ， 否 则 ， 就 得 配置 
Docker 以 代理 的 方式 访问 gcr.io， 或 者 配置 kubeadm 从 其 他 Registry 获 取 
相关 的 镜像 。 代 理 的 方法 是 在 [service] 配 置 段 中 添加 类 似 如 下 格式 的 配 
置 项 : Environment="HTTP_PROXY=http:VIP: PORT”， 或 
Environment="HTTPS_ PROXY=https://IP: PORT ”。 


另外 ，Docker 自 1.13 版 起 会 自动 设置 iptables 的 FORWARD 默 认 策 略 
为 DROP， 这 可 能 会 影响 Kubernetes 集 群 依赖 的 报 文 转发 功能 ， 因 此 ， 
需要 在 docker 服 务 启动 后 ， 重 新 将 FORWARD 链 的 默认 策略 设置 为 
ACCEPT， 方 式 是 修改 /usr/lib/systemd/system/docker.service 文 件 ， 
在 “EExecStart=/usr/bin/dockerd” 一 行 之 后 新 增 一 行 如 下 内 容 : 





ExecStartPost=/usr/sbin/iptables -P FORWARD ACCEPT 





上 面 各 步骤 设置 完成 后 即 可 启动 docker 服 务 ， 并 将 其 设置 为 随 系统 





引导 而 自动 启用， 相关 命令 如 下 : 





~]# Systemct1 daemon-reload 
~]# SystemctJ start docker.service 
~]# SystemctJ enable docker.service 





@ 提示 内 访问 DockerHub 下 载 镜像 的 速度 较 缓慢 ， 建 议 使 
用 国内 的 镜像 对 其 进行 加 速 ， 如 https://registry.docker-cn.com ， 另 外 ， 
中 国 科 技 大 学 也 提供 了 公共 可 用 的 镜像 加 速 服务 ， 其 URL 
为 https://docker.mirrors.ustc.edu.cn ， 将 其 定义 在 daemon.json 中 重启 
Docker 即 可 使 用 。 


A.2.2” 设 定 Kubernetes 集 群 节点 


kubelet 是 运行 于 集群 中 每 个 节点 之 上 的 Kubernetes 代 理 程 序 ， 它 的 
核心 功能 在 于 通过 API Server 获 取 调 度 至 自身 运行 的 Pod 资 源 的 PodSpec 
并 依 之 运行 Pod 对 象 。 事 实 上 ， 以 自 托 管 方式 部 晋 的 Kubernetes 集 群 ， 除 
了 kubelet 和 Docker 之 外 的 所 有 组 件 均 以 Pod 对 象 的 形式 运行 。 


1. 安 装 kubelet 及 kubeadm 

安装 kubelet 的 常用 方式 包含 如 下 几 种 。 快 速 迭 代 期 内 ，Linux 发 行 
商 提供 的 安装 包 通 常 版 本 较 低 ， 因 此 建议 采用 下 列 方式 的 第 一 种 或 第 二 
种 ， 本 章 将 采用 第 二 种 方式 。 

:Kubernetes 提 供 的 二 进 制 格式 的 tar 包 。 


Google 的 yum 仓 库 中 提供 的 rpm 包 ， 可 通过 国内 的 镜像 站 点 获取 ， 
例如 阿里 云 镜像 站 。 


:OS 发 行商 提供 的 安装 包 ， 例 如 Cent OS 7Extras 仓 库 中 的 Kubernetes 
相关 程序 包 。 











名 提示 “对 于 rpm 方 式 的 安装 来 说 ，kubelet、kubeadm 和 kubect 
等 是 各 自 独 立 的 程序 包 ，Master 及 各 Node 至 少 应 该 安装 kubelet 和 





kubeadm， 而 kubectl 则 只 需要 安装 于 客户 端 主机 即 可 ， 不 过 ， 由 于 依赖 
关系 它 通常 也 会 被 自动 安装 。 男 外 ，Google 提 供 的 kubelet rpm 包 的 yum 
仓库 托管 于 Google 站 点 的 服务 器 主机 之 上 ， 目 前 访问 起 来 略 有 不 便 。 玛 
运 的 是 ， 目 前 国内 的 阿里 云 等 镜像 (http://mirrors.aliyun.com ) 对 此 项 
目 也 有 镜像 提供 。 


首先 设 定 用 于 安装 kubelet、kubeadm 和 kubectl 等 组 件 的 yum 仓 库 ， 
编辑 配置 文件 /etcyum.repos.d/kubernetes.repo， 内 容 如 下 : 








[kubernetes] 

name=Kubernetes 

baseurl= https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/ 

enabled=1 

gpgcheck=1 

repo_gpgcheck=1 

gpgkey= https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https:// 
mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg 





而 后 执行 如 下 命令 即 可 安装 相关 的 程序 包 : 





[root@master ~]# yum install kubelet kubeadm kubectl 





2. 配 置 kubelet 


Kubernetes 自 1.8 版 本 起 强制 要 求 关 闭 系统 上 的 交换 分 区 (Swap) ， 
否则 kubelet 将 无 法 启动 。 当 然 ， 用 户 也 可 以 通过 将 kubelet 的 启动 参数 “-- 
fail-swap-on” 设 置 为 “false” 忽 略 此 限制 ， 尤 其 是 系统 上 运行 有 其 他 重要 
进程 且 系 统 内 存 资源 稍 嫌 不 足 时 建议 保留 交换 分 区 。 


编辑 kubelet 的 配置 文件 /etc/sysconfig/kubelet， 设 置 其 配置 参数 如 
下 ， 以 忽略 禁止 使 用 Swap 的 限制 : 





KUBELET_EXTRA_ARGS="--fail-swap-on=false" 





竺 配置 文件 修改 完成 后 ， 需 要 设 定 kubelet 服 务 开 机 自动 启动 ， 这 也 
是 kubeadm 的 强制 要 求 : 





[root@master~]#systemctl1 enable kubelet,.service 


A.2.3 集群 初始 化 


一 旦 Master 和 各 Node 的 Docker 及 kubelet 设 置 完 成 后 ， 接 着 便 可 以 在 
Master 节 点 上 执行 “kubeadm init” 命 令 进行 集群 初始 化 。kubeadm init 命 全 令 
文 持 两 种 初始 化 方式 ， 一 是 通过 命令 行 选项 传递 关键 的 参数 设 定 ， 男 一 
个 是 基于 yaml 格 式 的 专用 配置 文件 i 届 定 更 详细 的 配置 参数 。 下 面 分 别 给 
出 了 两 种 实现 方式 的 配置 步骤 ， 建 议 读者 采用 第 二 种 方式 。 


Master 初 始 化 方式 一 : 运行 下 面 的 命令 ， 便 可 完成 Master 的 初始 





[root@master ~]# kubeadm init \ 
--kubernetes-version=v1.12.1 \ 
--pod-network-cidr=10.244.0.0/16 \ 
--Service-cidr=10.96.0.0/12 \ 
--apiserver-advertise-address=0.0.0.0 \ 
--ignore-preflight-errors=Swap 





上 面 命令 的 选项 及 参数 设 定 决定 了 集群 运行 环境 的 众多 特性 设 定 ， 
这 些 设 定 对 于 此 后 在 集群 中 部 署 运 行 应 用 程序 至 关 重 要 。 


--kubernetes-version: 正在 使 用 的 Kubernetes 程 序 组件 的 版 本 号 ， 需 
要 与 kubelet 的 版 本 号 相同 。 


.--pod-network-cidr: Pod 网 络 的 地 址 范围 ， 其 值 为 CIDR 格 式 的 网 络 
地 址 ;使 用 flannel 网 络 插件 时 ， 其 默认 地 址 为 10.244.0.0/16。 


.--Service-cidr: Service 的 网 络 地 址 范围 ， 其 值 为 CIDR 格 式 的 网 络 地 
址 ， 默 认 地 址 为 10.96.0.0/12。 








.--apiserver-advertise-address: API server 通 告 给 其 他 组 件 的 IP 地 址 ， 
一 般 应 该 为 Master 节 点 的 耳 地 址 ，0.0.0.0 表 示 节 点 上 所 有 可 用 的 地 址 。 


.--ignore-preflight-errors: 忽略 哪些 运行 时 | 的 错误 信息 ， 其 值 为 
Swap 时 ， 表 示 忽 略 因 swap 未 关闭 而 导致 的 错误 。 


@ 提示 。 更 多 的 参数 请 参考 kubeadm 的 文档 ， 链 接地 址 


为 https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/ 。 


Master 初 始 化 方式 二 : kubeadm init 也 可 通过 配置 文件 加 载 配置 ， 
以 定制 更 丰富 的 部 团 选 项。 以 下 是 符合 前 述 命 令 设 定 方式 的 使 用 示例 ， 
不 过 ， 它 明确 定义 了 kubeProxy 的 模式 为 ipvs， 并 文 持 通过 修改 
imageRepository 的 值 来 修改 获取 系统 镜像 时 使 用 的 镜像 仓库 。 





apiVersion: kubeadm.k8s.io/vialpha2 
kind: MasterConfiguration 
kubernetesVersion: v1.12.1 
api: 
advertiseAddress: 172.20.0.70 
bindPort: 6443 
controlplaneEndpoint: "" 
imageRepository: k8s.gcr.io 
kubeProxy: 
config: 
mode: "ipvs" 
ipvs: 
ExcludeCIDRs: null 
minSyncPeriod: Os 
scheduler: "" 
syncPeriod: 30s 
kubeletconfiguration: 
baseConfig: 
cgroupDriver: cgroupfs 
clusterDNSs: 
- 10.96.0.10 
clusterDomain: cluster .1ocal 
failSwapon: false 
resolvConf: /etc/resolv.conf 
StaticPodPath: /etc/kubernetes/manifests 
networking: 
dnsDomain: cluster.local 
podSubnet: 10.244.0.0/16 
serviceSubnet: 10.96.0.0/12 





将 上 面 的 内 容 保存 于 配置 文件 中 ， 如 kubeadm-config.yaml， 而 后 执 
行 相 应 的 命令 即 可 完成 Master 初 始 化 : 





~]# kubeadm init --config kubeadm-config.yaml --ignore-preflight-errors=Swap 





无 论 使 用 上 述 哪 种 方法 ， 命 令 的 执行 过 程 都 会 执行 众多 部 署 操 作 并 
生成 相关 的 信息 ， 如 生成 配置 文件 ， 标 识 主 节 点 、 生 成 bootstrap token 及 
部 署 核心 附加 组 件 kube-proxy 和 kube-dns 等 ， 尤 其 是 为 集群 通信 安全 





于 /etc/kubernetes/pki 目 录 中 生成 的 一 众 密 钥 和 数字 证 书 ， 并 在 最 后 给 出 
了 kubectl 客 户 端 工具 的 配置 文件 生成 方式 以 及 随后 将 Node 加 入 集群 时 使 
用 的 引导 认证 令 牌 (bootstrap token) 等 ， 后 续 需 要 加 入 集群 的 各 Node 
都 将 使 用 该 引导 认证 令 牌 加 入 集群 。 不 同 版 本 的 kubeadm 其 输出 结果 或 
许 略 有 不 同 。 本 示例 特定 将 需要 注意 的 部 分 以 粗 体格 式 予 以 标识 ， 它 们 
是 后 续 步 又 的 重要 提示 信息 。 命 令 执行 的 结果 如 下 所 示 : 











[addons] Applied essential addon: CoreDNS 
[addons] Applied essential addon: kube-proxy 


Your Kubernetes master has initialized successfully! 
To start using your cluster, you need to run the following as a regular user: 


mkdir -p $HOME/.Kkube 
sudo cp -i /etc/kubernetes/admin.conf $HOME/.Kkube/config 
sudo chown $(id -u):$(id -g) $HOME/.Kkube/config 


You should now deploy a pod network to the cluster. 
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at: 
https://kubernetes.io/docs/concepts/cluster-administration/addons/ 


You can now join any number of machines by running the following on each node 
as root: 


kubeadm join 172.16.0.70:6443 --token sgm8ht.dxhqol10042i52fnz --discovery-token-c 
cert-hash sha256 :ffc0304409012dacbo7edbe886e36b4215cff94fa5cd48eee2f55c91e65 





根据 上 述 输 出 信息 的 提示 ( 粗 体 部 分 ) ， 完 成 集群 部 署 还 需要 执行 
三 类 操作 : 设 定 kubectl 的 配置 文件 、 部 署 网 络 附 件 以 及 将 各 Node 加 入 集 
群 。 下 面 就 来 讲解 如 何 进行 这 三 步 操作 。 


A.2.4 设 定 kubect 的 配置 文件 


kubectl 是 执行 Kubernetes 集 群 管理 的 核心 工具 。 默 认 情 况 下 ， 
kubectl 会 从 当前 用 户主 目录 (保存 于 环境 变量 HOME 中 的 值 ) 中 的 隐藏 
目录 .kube 下 名 为 config 的 配置 文件 中 读 取 配置 信息 ， 包 括 要 接 入 
Kubernetes 集 群 、 以 及 用 于 集群 认证 的 证 书 或 令 牌 等 信息 。 集 群 初始 化 
时 ，kubeadm 会 自动 生成 一 个 用 于 此 类 功能 的 配置 文 
件 /etc/kubernetes/admin.conf， 将 它 复 制 为 用 户 的 $HOME/.kube/config 文 
件 即 可 直接 使 用 。 这 里 以 Master 节 点 上 的 root 用 户 为 例 进行 操作 ， 不 
过 ， 在 实践 中 应 该 以 普通 用 户 的 映 份 进行 : 














[root@master ~]# mkdir -p $HOME/ ,kube 
[root@master ~]# cp -i /etc/kubernetes/admin.conf $HOME/.kube/config 





至 此 为 止 ， 一 个 Kubernetes Master 节 点 已 经 基本 配置 完成 。 接 下 来 
即 可 通过 API Server 来 验证 其 各 组 件 的 运行 是 否 正 常 。kubectl 有 着 众 多 
子 命令 ， 其 中 “get compontsstatuses” 即 能 显示 出 集群 组 件 当前 的 状态 ， 
也 可 使 用 其 简写 格式 “get cs”: 





[root@master ~]# kubectl get cs 


NAME STATUS MESSAGE ERROR 
scheduler Healthy ok 
controller-manager Healthy ok 

etcd-0 Healthy {"health":; "true"} 





若 上 面 命令 结果 的 STATUS 字段 为 "Healthy”， 则 表示 组 件 处 于 健康 
运行 状态 ， 盏 则 需要 检查 其 错误 所 在 ， 必 要 时 可 使 用 “kubeadm reset” 命 
令 重 置 之 后 重新 进行 集群 初始 化 。 


男 外 ， 使 用 “kubectl get nodes” 命 令 能 够 获取 集群 节点 的 相关 状态 信 
轧 ， 如 下 命令 结果 显示 了 Master 方 点 的 状态 为 "NotReady”(〈 未 就 绪 ) ， 
这 是 因为 集群 中 尚未 安装 网 络 插件 所 致 ， 执 行 完 后 面 的 其 他 步骤 后 它 即 
自行 转 为 “Ready”: 





[root@master ~]# kubectl1 get nodes 
NAME STATUS ROLES AGE VERSION 
master .ilinux.io NotReady master 4m V1.12.1 





A.2.5 部 普 网 络 插件 








为 Kubernetes 提 供 Pod 网 络 的 插件 有 很 多 ， 目 前 最 为 流行 的 是 flannel 
和 Calico。 相 比较 来 说 ，flannel 以 其 简单 、 易 部 署 、 易 用 等 特性 广 受 用 
户 欢 迎 。 基 于 kubeadm 部 署 时 ，flannel 同 样 运行 为 Kubernetes 集 群 的 附 
件 ， 以 Pod 的 形式 部 署 运行 于 每 个 集群 节点 上 以 接受 Kubernetes 集 群 管 
理 。 事 实 上， 也 可 以 直接 将 flannel 程 序 包 安 装 并 以 守护 进程 的 方式 运行 
于 集群 节点 上 ， 即 以 非 托管 的 方式 运行 。 部 署 方式 既 可 以 是 获取 其 资源 
配置 清单 于 本 地 而 后 部 署 于 集群 中 ， 也 可 以 直接 在 线 进行 应 用 部 署 。 部 
署 命令 是 “kubectl apply” 或 “kubectl create”， 例 如 ， 下 面 的 命令 将 直接 使 








用 在 线 的 配置 清单 进行 fannel 部 署 : 





[root@master ~]# kubectl1 apply -f https://raw.githubusercontent.com/coreos/flannel/ 
master/Documentation/kube-flannel.yml 





kubectl 可 根据 定义 资源 对 象 的 清单 文件 将 其 提交 给 API Server 以 管 
理 资源 对 象 ， 如 使 用 “kubectl apply-f/PATH/TO/MANIFEST”* 命 令 即 可 根 
据 清 单 设置 资源 的 日 标 状态 。kubectl 的 具体 使 用 会 在 后 面 的 章节 进行 详 


细 介 绍 。 


配置 flannel 网 络 插件 时 ，Master 节 点 上 的 Docker 首 先 会 去 获取 
flannel 的 镜像 文件 ， 而 后 根据 镜像 文件 启动 相应 的 Pod 对 象 。 符 其 运行 


完成 后 再 次 查看 集群 中 的 节点 状态 可 以 看 出 Master 已 经 变 为 “Ready” 状 
区 


4UDv 





[root@master ~]# kubectl1 get nodes 
NAME STATUS ROLES AGE VERSION 
master .ilinux.io Ready master 10m V1.12.1 





@ 提示 。 kube-system|grep flannel” 命 令 的 结果 显示 Pod 的 状态 为 
Running 时 即 表示 网 络 插件 fannel 部 署 完 成 。 


A.2.6 添加 Node 至 集群 中 


Master 各 组 件 运 行 正 党 后 即 可 将 各 Node 添 加 至 集群 中 。 配 置 节点 
时 ， 需 要 事先 参考 前 面 “设置 容器 运行 环境 ”和 “ 设 定 Kubernetes 集 群 节 
点 ”两 节 中 的 配置 过 程 设置 好 Node 主 机 ， 而 后 即 可 在 Node 主 机 上 使 
用 “kubeadm join” 命 令 将 其 加 入 集群 中 。 不 过 ， 为 了 系统 安全 起 见 ， 任 
何 一 个 试图 加 入 到 集群 中 的 节点 都 需要 先 经 由 API Server 完 成 认证 ， 其 
认证 方法 和 认证 信息 在 Master 上 运行 的 “kubeadm init” 命 令 执行 初始 化 时 
将 于 输出 结果 信息 的 最 后 一 部 分 中 提供 。 


例如 ， 类 似 如 下 命令 即 可 将 node01.ilinux.io 加 入 集群 中 ， 它 使 用 和 集 
群 初始 化 时 生成 的 认证 令 牌 (token) 信息 进行 认证 。 另 外 ， 同 样 出 于 
为 操作 系统 及 其 他 应 用 保留 交换 分 区 之 目的 ， 在 kubeadm join 命令 上 添 





加 了 “--ignore-preflight-errors=Swap” 选 项 : 





[root@node01 ]# kubeadm join 172.16.0.70:6443 --ignore-preflight-errors=Swap 
--token sgm8ht.dxhqol0042i52fnz --discovery-token-ca-cert-hash \ 
sha256:ffc0304409012dacb07edbe886e36b4215cff94fa5cd48eee2f55c91e65b0a01 





提供 给 API Server 的 bootstrap token 认 证 完成 后 ，kubeadm join 命令 会 
为 后 续 Master 与 Node 组 件 间 的 双 同 ssyts 认 证 生成 私 钥 及 证 书签 署 请 
求 ， 并 由 Node 在 首次 加 入 集群 时 提交 给 Master 问 的 CA 进行 签署 。 默 认 
情况 下 ，kubeadm 配 置 kube-apiserver 启 用 了 bootstrapTLS 功 能 ， 并 文 持 证 
书 的 自动 签署 。 于 是 ，kubelet 及 kube-proxy 等 组 件 的 相关 私 钥 和 证 书 文 
Er 令 执 行 结束 后 便 可 自动 生成 ， 它 们 默认 保存 于 /var/lib/kubelet/pki 
目录 中 。 


在 每 个 节点 上 重复 上 述 步骤 就 能 够 将 其 加 入 集群 中 。 所 有 节点 加 入 
完成 后 ， 即 可 使 用 “kubectl get nodes” 命 令 验证 集群 的 节点 状态 ， 包 括 各 
节点 的 名 称 、 状 态 就 绪 与 否 、 角 色 “【〈 是 否 为 节点 Master) 、 加 入 集群 的 
时 长 以 及 程序 的 版 本 等 信息 : 








[root@master ~]# kubectl1 get nodes 


NAME STATUS ROLES AGE VERSION 
master .ilinux.io Ready master 25m V1.12.1 
node01.ilinux.io Ready <none> 1m V1.12.1 
node02.ilinux.io Ready <none> 1m V1.12.1 
node03.ilinux.io Ready <none> 32S V1.12.1 





到 此 为 止 ， 使 用 kubeadm 构 建 Kubernetes 集 群 已 经 完成 。 后 续 若 有 
Node 需 要 加 入 ， 其 方式 均 可 使 用 此 节 介 绍 的 方式 来 进行 。 


A.2.7 获取 集群 状态 信息 


Kubernetes 集 群 以 及 部 署 的 插件 提供 了 多 种 不 同 的 服务 ， 如 此 前 部 
署 过 的 API Server、kube-dns 等 。API 客 户 端 访问 集群 时 需要 事先 知道 
API Server 的 通告 地 址 ， 管 理 员 可 使 用 “kubectl cluster-info” 命 令 了 解 到 这 
些 信 县 : 





[root@master ~]# kubect1 cluster-info 
Kubernetes master is running at https://172.16.0.70:6443 


CoreDNS is running at https://172.16.0.70:6443/api/vi/namespaces/kube-system/ 
services/kube-dns:dns/proxy 





Kubernetes 集 群 Server 端 和 Client 痊 的 版 本 等 信息 可 以 使 用 “kubectl 
version” 命 令 进 行 查看 : 





[root@master ~]# kubectl1 version --short=true 
Client Version: v1.12.1 
Server Version: v1.12.1 





A.3 ”从 集群 中 移 除 市 反 


运行 过 程 中 ， 耕 有 市 反 需 要 从 正常 运行 的 集群 中 移 除 ， 则 可 使 用 如 
下 步骤 来 进行 。 


1) 在 Master 上 使 用 如 下 命令 “ 排 干 ”( 迁 移 至 集群 中 的 其 他 节点 ) 当 
前 节点 之 上 的 Pod 资 源 并 移 除 Node 节 点 : 








~]# kubect1 drain NODE_ID --delete-local-data --force --ignore-daemonsets 
~]# kubect1 delete node NODE_ID 





, 而 后 在 要 删除 的 Node 上 执行 如 下 命令 重 置 系统 状态 便 可 完成 移 
除 操作 : 





~]# kubeadm reset 





A.4 重新 生成 用 于 节点 加 入 集群 的 认证 命令 


如 果 忘 记 了 记录 Master 主 机 的 kubeadm init 命 令 执行 结果 中 用 于 让 节 
点 加 入 集群 的 kubeadm join 命 令 及 其 认证 信息 ， 则 需要 分 别 通过 kubectl 
获取 认证 令 牌 及 验证 CA 公 钥 的 哈 希 值 。 


“kubeadm token list” 能 够 获取 到 集群 上 存在 认证 令 牌 ， 定 位 到 其 中 
DESCRIPTION 字段 中 标识 为 由 “kubeadm init” 命 令 生 成 的 行 ， 其 第 一 字 


段 TOKEN 中 的 令 牌 即 为 认证 令 牌 。 而 验证 CA 公 钥 的 哈 希 值 〈discovery- 
token-ca-cert-hash)〉 的 获取 命令 则 略微 复杂 ， 其 完成 格式 如 下 所 示 : 





~]# openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin 
-outform der 2>/dev/null | openssl dgst -Sha256 -hex | sed 's/^.* //' 





而 后 ， 将 上 述 两 个 命令 生成 的 结果 合成 为 如 下 格式 的 kubeadm join 
命令 即 可 用 于 让 Node 加 入 集群 中 ， 其 中 的 TOKEN 可 蔡 换 为 上 面 第 一 个 
命令 的 生成 结果 ，HASH 可 蔡 换 为 第 二 个 命令 的 生成 结果 : 








kubeadm join 172.16.0.70:6443 --token TOKEN --discover-token-ca-cert-hash HASH 





最 后 ， 需 要 提醒 读者 注意 的 是 ，Kubernetes 项 目 目前 处 于 快速 欠 代 
时 期 ， 其 版 本 号 演进 速度 较 快 ， 因 此 ， 读 者 在 测试 时 默认 安装 的 程序 版 
本 与 本 书 使 用 的 极 有 可 能 存在 痢 不 同 ， 甚 全 连 部 普 步 又 都 可 能 会 及 生 改 
变 。 建 议 读者 参考 作者 的 微 信 公 众 号 还 ubernetes 以 获取 较 新 的 部 车 文 
档 ， 微 信 公 众 号 二 维 码 如 下 。 








附录 B 部署 GlusterFS 及 Heketi 


在 实践 Kubernetes 的 StatefulSet 及 各 种 需要 持久 存储 数据 的 组 件 或 功 
能 时 ， 通 常会 用 到 PV 的 动态 供给 功能 ， 这 就 需要 用 到 文 持 此 类 功能 的 
存储 系统 。 在 各 类 支持 PV 动态 供给 功 和 Eb 的 存储 系统 中 ，GlusterFS 的 设 
定 较为 简单 ， 因 此 本 书 用 到 的 各 类 动态 存储 功能 将 以 此 为 例 进行 说 明 。 
本 章 将 试图 为 读者 提供 一 个 设置 A GlusterFS 存 储 系 统 的 简 
单 说 明文 档 ， 而 不 是 对 GlusterFS 进 行 全 面 介绍 。GlusterFS 的 架构 如 图 B- 
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图 B-1 ”GlusterFS 架 构 





本 示例 中 ，gfs01.ilinux.io、gfs02.ilinux.io 和 gfs03.ilinux.io 三 个 节点 
组 成 了 GlusterFS 存 储 集群 (如 图 B-1 所 示 》， 并 将 gfs01 节 点 部 堵 为 ， 
heketi 服 务 器 。 各 节点 上 ，sdb、sdc 和 sdd 用 于 为 GlusterFS 提 供 存储 空 
间 。 


B.1 部 署 GlusterFS 集 群 


四 分 别 在 三 三 个 节点 上 安装 glusterfs-server 程 序 包 ， 并 启动 
glusterfsq 服 务 ， 命 节令 令 如 下 : 





# yum install centos-release-gluster 
# yum --enablerepo=centos-gluster*-test install glusterfs-server 
# SyStemctJ start glusterd.service 





第 二 步 ， 在 任 一 广 扩 上 上 使用 “glusterfs peer probe” 命 令 “ 发 现 ” 其 他 节 
点 ， 组 建 GlusterFS 集 群 。 命 命令 格式 为 “peer Oe 
address>}”， 例 如 ， 在 gfs01 上 运行 如 下 命 





[root@gfs01 ~]# gluster peer probe gfs02.ilinux.io 
[root@gfs01 ~]# gluster peer probe gfs03.ilinux.io 





第 三 步 ， 通 过 节点 状态 命令 “gluster peer status” 确 认 各 节点 已 经 加 入 
同一 个 可 信 池 中 (trusted pool) : 





[root@gfs01 ~]# gluster peer status 
Number of Peers: 2 


Hostname: 172.16.2.37 

Uuid: eof7e3cf-f856-4f95-a7d9-ad2e99cc455b 
State: Peer in Cluster (Connected ) 

Other names : 

gfs02.ilinux.io 


Hostname: 172.16.2.38 

Uuid: al025d59-ac33-4265-a4d8-667b2d8a3a5c 
State: Peer in Cluster (Connected) 

Other names: 

gfs03.ilinux.io 


二 一 


B.2 ”部 着 Heketi 


Heketi 为 管理 GlusterFS 存 储 卷 的 生命 周期 提供 了 一 个 RESTful 管 理 
接口 ， 借 助 于 Heketi， 像 OpenStack Manila、Kubernetes 和 OpenShift 这 样 
的 云 服 务 可 以 动态 调配 Gluster 存 储 卷 。Heketi 能 够 自动 确定 整个 集群 的 
brick 位 置 ， 并 确保 将 brick 及 其 副本 放置 在 不 同 的 故障 域 中 。 男 外 ， 
0 的 Gluster 存 储 集群 ， 并 文 持 云 服务 提供 网 络 文件 
子 情 。 


有 了 Heketi， 存 储 管理 员 不 必 再 管理 或 配置 brick、 磁 盘 或 可 信 存 储 
池 (trusted pool) ，Heketi 服 务 将 为 管理 员 管 理 毛 有 硬件 ， 并 使 其 能 
按 需 分 配 存储 。 不 过 ， 在 Heketi 中 注册 的 任何 磁盘 都 必须 以 原始 格式 提 
供 ， 而 不 能 是 创建 过 文件 系统 的 磁盘 分 区 。Heketi 架 构 如 图 B-2 所 示 。 
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图 B-2 ”Heketi 架 构 


本 部 署 示例 将 gfs01.ikubernees,io 节 点 用 作 Heketi 服 务 器 ， 因 此 以 下 
所 有 步骤 均 在 gfs01 上 执行 。 


B.2.1 安装 并 启动 Heketi 服 务 器 


首先 安装 Heketi。 ee 配置 好 相关 的 仓 
库 后 即 可 运行 如 下 安装 命 








[root@gfs01~]#yum install heketi heketi-client 





第 二 步 ， 配 置 Heketi 用 户 能 够 基于 SSH 密 钥 的 认证 方式 连接 至 
GluserFS 集 群 中 的 各 节点 ， 并 拥有 相应 节点 的 管理 权限 : 





# ssh-keygen -f /etc/heketi/heketi key -t rsa -N '' 
# chown heketi:heketi /etc/heketi/heketi key* 
# for host in gfs01 gfs02 gfs03; do \ 
ssh-copy-id -i /etc/heketi/heketi key.pub root@${host}.ilinux.io; done 





第 三 步 ， 设 置 Heketi 的 主 配置 文件 /etc/heketi/heketi.json， 定 义 服务 
监听 的 端口 、 认 证 及 连接 Gluster 存 储 集群 的 方式 。 一 个 配置 示例 如 下 : 





"port": "8080", 
"use_auth": false, 
"jwt": { 
"admin": { 
"key": "admin Secret" 


了 
"user": { 
"key": "user Secret" 


} 


¥ 
"glusterfs": { 
"executor": "ssh", 
"sshexec": 
"keyfile": "/etc/heketi/heketi key", 
"User": "root", 
"port": "22", 
"fstab": "/etc/fstab" 


}, 
"db": "/var/lib/heketi/heketi.db", 
"loglevel": "debug" 


看 要 局 用 连接 Heketi 的 认证 ， 则 需要 将 “use_auth” 参 数 的 值 设 置 
为 “true”， 并 在 *jwt{j}? 配 置 段 中 为 各 用 户 设 定 相应 的 密码 ， 用 户 名 和 密 
码 都 可 以 自 定 义 。“glusterfs{}” 配 置 段 用 于 指定 接 入 Gluster 存 储 集群 的 
认证 方式 及 认证 信息 。 





名 提示 。 奉 局 用 了 认证 功能 ， 则 于 Kubermetes 集 群 中 配置 存储 类 
时 需要 设置 相应 的 认证 信息 。 


第 四 步 ， 启 动 Heketi 服 务 : 





# systemctl1 enable heketi 
# systemctl1 start heketi 








需要 注意 的 是 ， 将 Gluster 存 储 集群 的 功能 托管 于 Heketi 之 后 便 不 能 
2 中 使 用 命令 管理 存储 卷 ， 以 免 与 Heketi 数 据 库 中 存储 的 信息 
一致。 


第 五 步 ， 癌 Heketi 发 起 访问 测试 请 求 ， 无 须 认 证 时 ， 使 用 curl 命 令 
即 能 完成 测试 : 





# curl http://gfs01:8080/hello 
Hello from Heketi 





石 Heketi 甩 用 了 认证 功能 ， 则 需要 使 用 heketi-cli 命 令 进行 测试 ， 命 
令 格式 如 下 ; 





heketi-cli --Server http://<server:port> --user <user> --secret <secret> cluster li: 





B.2.2 设置 Heketi 系 统 拓扑 


拓扑 信息 用 于 让 Heketi 确 认可 使 用 的 市 把 、 人 磁盘 和 集群 ， 管 理 员 必 
须 目 行 确定 闻 扣 故障 域 和 市 点 集群 。 故 障 域 是 赋予 一 组 太 点 的 整数 值 ， 
这 组 市 点 共 至 相同 的 交换 机 、 电 源 或 其 他 任何 会 导致 它们 同时 失效 的 组 
件 。 管 理 员 必须 确定 哪些 节点 构成 一 个 集群 ，Heketi 使 用 这 些 信 息 来 确 








保 跨 故 障 域 中 创建 副本 ， 从 而 提供 数据 的 见 余 能 力 。Heketi 支 持 多 个 
Gluster 存 储 集群 ， 这 为 管理 员 提 供 了 创建 SSD、SAS、SATA 或 为 用 户 
提供 特定 服务 质量 的 任何 其 他 类 型 的 群集 的 选项 。 


命令 行 客户 端 heketi-clij 通 过 加 载 预定 义 的 集群 拓扑 ， 从 而 添加 节点 
到 集群 中 ， 以 及 将 磁盘 关联 到 市 点 上 。 要 使 用 heketi-cli 加 载 拓 扑 文 件 ， 
可 通过 以 下 命令 完成 : 





# export HEKETI_CLI_ SERVER=http://<heketi server:port> 
# heketi-cli topology load --json=<topology_file> 








一 个 适用 于 当前 配置 环境 的 示例 配置 如 下 所 示 
Getc/heketi/topology_demo.json) ， 它 将 根据 Gluster 和 存储 集群 的 实际 环 
境 把 gfs01、gfs02 和 gfs03 三 个 节点 定义 在 同一 个 集群 中 ， 并 指明 各 节点 
上 可 用 于 提供 存储 空间 的 磁盘 设备 : 








{ 


"clusters": [ 
"nodes": [ 


"node": { 
"hostnames": { 
"manage": [ 
"172.16.2.36" 


], 

"storage": [ 
"172.16.2.36" 

] 


了 
"zone": 1 


"devices": [ 
"/dev/sdb", 
"/dev/sdc", 
"/dev/sdd" 

] 

外 


"node": { 
"hostnames": { 
"manage": [ 
"172.16.2.37" 
], 
"storage": [ 
"172.16.2.37" 
] 


了 
"zone": 1 


"devices": [ 
"/dev/sdb", 
"/dev/sdc", 
"/dev/sdd" 


"node": { 
"hostnames": { 
"manage": [ 
"172.16.2.38" 
], 
"storage": [ 
"172.16.2.38" 
] 
}, 


"zone": 1 

}, 

"devices": [ 
"/dev/sdb", 
"/dev/sdc", 
"/dev/sdd" 








而 后 运行 如 下 命令 加 载 拓 扑 信息 ， 从 而 完成 集群 配置 。 此 命令 会 生 
成 一 个 集群 ， 并 为 其 添加 的 各 节点 生成 随机 ID 号 : 





# export HEKETI_CLI_SERVER=http://gfs01.ilinux.io:8080 
# heketi-cli topology load --json=topology_demo.json 








而 后 运行 如 下 命令 碍 看 集群 的 状态 信息 : 





# heketi-cli cluster Info ba7657cf60195432d8c0b4e3c2c94d59 
Cluster id: ba7657cf60195432d8c0b4e3c2c94d59 

Nodes: 

2a73c6123e4a05ceb050bc5c433c6a07 
613754fe6267e3d7f1a731ce2e0ab94a 
8b4e57a8ce4e5640b6cc845915769f8d 

VolLumes : 





“heketi-cli volume create --size=<size in Gb> [options]” 能 够 创建 存储 
卷 ， 例 如 ， 下 面 的 命令 测试 即 用 于 创建 一 个 存储 卷 : 





# heketi-cli volume create --size=20 


Name: Vol _ 43b859b65d4ad8eode47065b2aca7e41 

Size: 20 

Volume Id: 43b859b65d4ad8e0de47065b2aca7e41 

Cluster Id: ba7657cf60195432d8c0b4e3c2c94d59 

Mount: 172.16.2.36:VvVol 43b859b65d4ad8eode47065b2aca7e41 

Mount Options: backup-volfile-servers=172.16.2.37,172.16.2.38 
Durability Type: replicate 

Distributed+Replica: 3 





而 后 在 要 使 用 的 远程 存储 卷 的 节点 上 安装 GlusterFS 和 glusterfs-fuse 
程序 包 ， 提 供 GlusterFS 客 户 端 驱动 及 对 GlusterFS 文 件 系 统 的 运行 ， 并 基 
于 GlusterFS 文 件 系 统 类 型 挂 载 使 用 确认 无 误 后 即 可 删除 测试 卷 。 删 除 
Heketi 卷 的 命令 为 “heketi-cli volume delete<vol id>”， 如 删除 前 面 创建 的 
存储 卷 ， 可 使 用 以 下 命令 : 





# heketi-cli volume delete 43b859b65d4ad8e0de47065b2aca7e41 
Volume 43b859b65d4ad8e0de47065b2aca7e41 deleted 





至 此 为 止 ， 一 个 支持 动态 存储 卷 配 置 的 GlusterFS 存 储 集群 即 设 置 完 
成 ， 用 户 既 可 于 Kubernetes 中 通过 PVC 请 求 使 用 某 事 先 创建 完 成 的 
GlusterFS 存 储 卷 ， 也 可 把 Heketi 配 置 为 存储 类 ， 而 后 提供 PV 的 动态 供给 
功能 。 


